А не может ли красное смещение быть связанным с самим пространством? Например, кванты теряют энергию не из-за расширения пространства, а просто из-за длины пробега?
На мой дилетантский взгляд, всегда интересовало, если гравитация таки квантуется, будут ли гравитоны увлекаться черной дырой, как это увлекаются фотоны?
По идее, Expression.* достаточно плотно привязаны к C#\VB.NET. Если автор ставит себе задачу создать собсвтенный язык программирования, то используя Expression он получит скорее транспайлер.
Не лучшая идея запускать по потоку на каждый обработчики эвентов. ThreadPool.QueueWorkItem предпочтительней. И не забываем про SynchronizationContext, когда работаем с голыми потоками или тред плулом.
Как-то из внешенго мира вопрос в заголовке выглядит как теплое с мягким. Лямбда-функция — это неименованная функция, которую можно объявить в теле метода. Замыкания — возможность использовать перменные, внешние для объявленной функции. Соотвественно, лямбда-функции могут использовать механизм замыканий, а могут и нет — и поддержка замыканий для лямбда функций может быть в языке, а может и нет. Конечно, все эти три вещи идут достаточно близко — лямбда-функции, функции как объект первого порядка (грубо говоря, переменные типа «функции») и замыкания. Язык может не поддерживать лямбда-функции — именно как неименованные функции, но уметь замыкания и наоборот.
Я совершенно не против замыканий. Я против использования нечистых функций в linq в частности и в функциональных подходах (linq, как ни крути, это кусочек функционального мира в императивном C#) в общем. Все ваши примеры можно переписать с использованием чистых функций, и, отвечая на ваш вопрос ниже, они вполне подходят для обучения студентов. Горы циклов, это, конечно, не очень, но такое использование linq, на мой взгляд, усложняет его понимание и уводит несколько в сторону от его базовых понятий — комбинации функций, ленивые вычисления и так далее.
Я, наверное, неправильно выразился — на личности переходить не хотелось, коненчо. Вопросы сверху — это те вопросы, которые я бы задал на собеседовании в ответ на такое задание.
На мой взгляд, такое задание наоборот, помешает мне увидеть алгоритм — это набор триков, который действительно выглядит как обфускация. Проверить этим мышление — наверное, да, получится. Но эта задачка (надеюсь) все-таки слишком далека от реального кода.
Например, мы на собеседовании даем вот такой вот код «на-объяснить»:
var groupToDictionary = function(arr, keyFunction) {
var objToReturn = {};
arr.forEach(function(item) {
var key = keyFunction(item);
if (!objToReturn.hasOwnProperty(key)){
objToReturn[key] = [];
objToReturn[key].getKey = function() { return key; };
}
objToReturn[key].push(item);
});
return objToReturn;
};
Банальная функция, на которой, к сожалению, многие отваливаются. Но функция реальная, без подвохов.
Второго. Если б я увидел такой код на собеседовании — я бы усомнился в адекватности собеседующих и задумался о вакансии в принципе. Мне придется разбираться с таким кодом на работе? Вы реально так пишите? Какие мои навыки вы проверяете?
Ну уж нет, именно в ранг мантры. Такой код сложно читать, практически невозможно рефакторить. То же самое касается goto. Такой код в продакшене — повод поговорить про профнепригодность.
И еще пару слов про код — очень плохая практика использовать в методах, которые вызываются в linq сайд эффекты — присваивание переменных и подобное:
Dictionary<char, int> ra = w.ToDictionary(ch => ch, ch => (o = ("" + o)[0] == '1' ? o * 2 : o * 5) / 2);
Если вам нужны локальные переменные — используйте let. Плюс странная констркуция ("" + o)[0] — это первый символ числа? Тогда пишите явно o.ToString()[0]. Но все равно присовение внутри linq функций — это плохо. Тоже самое и здесь
Также нежелательно смешивать linq синтаксис и вызовы extension методов. Понятно, что во втором ToRoman нужен последний First(), но тогда либо весь предыдущий запрос писать в linq синтаксисе, либо весь в цепочку вызовов.
К сожалению, Dictionary<,> в общем случае не сохраняет порядок добавления ключей. Если я не ошибаюсь, порядок теряется при перебалансировке. В вашем случае лучше подойдет просто список пар (ну или Tuple-ов).
2. Там же, плюс «Долги», плюс «Проекты»
4. support.zenmoney.ru/topics/5-nastrojka-kreditnyih-kart-i-kreditov
btw, не имею к ним отношения, просто нравится продукт :)
На мой взгляд, такое задание наоборот, помешает мне увидеть алгоритм — это набор триков, который действительно выглядит как обфускация. Проверить этим мышление — наверное, да, получится. Но эта задачка (надеюсь) все-таки слишком далека от реального кода.
Например, мы на собеседовании даем вот такой вот код «на-объяснить»:
Банальная функция, на которой, к сожалению, многие отваливаются. Но функция реальная, без подвохов.
Аналог let — это Select с анонимным типом внутри.
А вы действительно учите этому студентов?
Если вам нужны локальные переменные — используйте
let. Плюс странная констркуция ("" + o)[0] — это первый символ числа? Тогда пишите явно o.ToString()[0]. Но все равно присовение внутри linq функций — это плохо. Тоже самое и здесь++i лучше заменить на i+1.
И во втором ToRoman.
Также нежелательно смешивать linq синтаксис и вызовы extension методов. Понятно, что во втором ToRoman нужен последний First(), но тогда либо весь предыдущий запрос писать в linq синтаксисе, либо весь в цепочку вызовов.