Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Аноним, Вы писали:

А>>Приведите пожалуйста пример в каком практическом случае эффективно использовать ленивое вычисление.

U>В плане производительности полезны, если нужны тяжелые промежуточные объекты. Ленивость в таких задачах позволяет получить приличный выигрыш по пиковой памяти и существенный в производительности (десятки процентов). Но если промежуточные объекты легкие, тогда смысла использовать ленивость нет, производительность обычно наоборот хуже.

Это вообще говоря фигня. Ленивость позволяет наиболее просто записывать многие алгоритмы.
Например можно построить дерево решений, полное дерево решений, оно все равно ленивое и реально будет отсутствовать в памяти, а потом методом ветвей и границ отсекать ненужные решения.

В энергичном языке придется передавать внутрь вычислителя контекст, который внутри будет проверять отсекать текущую ветку или продолжать поиск. Или придется вручную эмулировать ленивость с запоминанием.

Ленивость дает максимальную свободу декомпозиции задач и композиции решений.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, gandjustas, Вы писали:

G>>>>>>3)Ленивость должна быть с запоминанием, те если ленивое выражение было вычислено, но оно не должно вычисляться второй раз
_FR>>>>>"Должна быть" и для итераторов?
G>>>>Итераторы как раз обладают наблюдаемыми побочными эффектами, так что ленивости для них быть не должно в принципе.
_FR>>>То есть и yield return "не должно быть в принципе"?

G>>Как с yield никаких проблем нету. yield сам по себе никаких побочных эффектов не имеет. а вот использование IEnumerator еще как имеет.

_FR>Не понял yield же создаёт ни что иное, как нечто ленивое. Причем "без запоминания". Почему же "нету проблем"?

_FR>И в чём смысл разделять yield и IEnumerator?

_FR>

_FR>    static IEnumerator M() {
_FR>      yield return 1;
_FR>    }
_FR>

_FR>Может, имеет смысл описать подробнее, какие проблемы даёт "использование IEnumerator" при том, что "с yield никаких проблем нету"?

IEnumerator — объект с состоянием, прицепить к нему ленивость никак не выйдет.
Весь LINQ и yield создает ленивую коллекцию (без запоминания), что может приводить к проблемам.
Например я один раз напоролся и долго не мог понять что происходит:

var parameters = someSeq.Select(e => Expression.Parameter(...));
var l = Expression.Lambda(Expression.Block(parameters,...), parameters.ToArray());

Отладчик показывал одинаковые параметры, хотя метод Compile ругался что переменные внутри блока не найдены.

Здравствуйте, gandjustas, Вы писали:

G>>>>>>>3)Ленивость должна быть с запоминанием, те если ленивое выражение было вычислено, но оно не должно вычисляться второй раз
_FR>>>>>>"Должна быть" и для итераторов?
G>>>>>Итераторы как раз обладают наблюдаемыми побочными эффектами, так что ленивости для них быть не должно в принципе.
_FR>>>>То есть и yield return "не должно быть в принципе"?
G>>>Как с yield никаких проблем нету. yield сам по себе никаких побочных эффектов не имеет. а вот использование IEnumerator еще как имеет.
_FR>>Не понял yield же создаёт ни что иное, как нечто ленивое. Причем "без запоминания". Почему же "нету проблем"?
_FR>>И в чём смысл разделять yield и IEnumerator?

_FR>>    static IEnumerator M() {
_FR>>      yield return 1;
_FR>>    }

_FR>>Может, имеет смысл описать подробнее, какие проблемы даёт "использование IEnumerator" при том, что "с yield никаких проблем нету"?

G>IEnumerator — объект с состоянием, прицепить к нему ленивость никак не выйдет.
G>Весь LINQ и yield создает ленивую коллекцию (без запоминания), что может приводить к проблемам.
G>Например я один раз напоролся и долго не мог понять что происходит:
G>

G>var parameters = someSeq.Select(e => Expression.Parameter(...));
G>var l = Expression.Lambda(Expression.Block(parameters,...), parameters.ToArray());
G>

G>Отладчик показывал одинаковые параметры, хотя метод Compile ругался что переменные внутри блока не найдены.

Так в чём всё-таки на ваш взгляд проблема-то? Сейчас вы сказали, что "yield создает ленивую коллекцию (без запоминания), что может приводить к проблемам", а постом ранее — "с yield никаких проблем нету" Как это нужно понять?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, gandjustas, Вы писали:

G>>>>>>>>3)Ленивость должна быть с запоминанием, те если ленивое выражение было вычислено, но оно не должно вычисляться второй раз
_FR>>>>>>>"Должна быть" и для итераторов?
G>>>>>>Итераторы как раз обладают наблюдаемыми побочными эффектами, так что ленивости для них быть не должно в принципе.
_FR>>>>>То есть и yield return "не должно быть в принципе"?
G>>>>Как с yield никаких проблем нету. yield сам по себе никаких побочных эффектов не имеет. а вот использование IEnumerator еще как имеет.
_FR>>>Не понял yield же создаёт ни что иное, как нечто ленивое. Причем "без запоминания". Почему же "нету проблем"?
_FR>>>И в чём смысл разделять yield и IEnumerator?
_FR>

_FR>>>    static IEnumerator M() {
_FR>>>      yield return 1;
_FR>>>    }
_FR>

_FR>>>Может, имеет смысл описать подробнее, какие проблемы даёт "использование IEnumerator" при том, что "с yield никаких проблем нету"?

G>>IEnumerator — объект с состоянием, прицепить к нему ленивость никак не выйдет.
G>>Весь LINQ и yield создает ленивую коллекцию (без запоминания), что может приводить к проблемам.
G>>Например я один раз напоролся и долго не мог понять что происходит:
G>>

G>>var parameters = someSeq.Select(e => Expression.Parameter(...));
G>>var l = Expression.Lambda(Expression.Block(parameters,...), parameters.ToArray());
G>>

G>>Отладчик показывал одинаковые параметры, хотя метод Compile ругался что переменные внутри блока не найдены.

_FR>Так в чём всё-таки на ваш взгляд проблема-то? Сейчас вы сказали, что "yield создает ленивую коллекцию (без запоминания), что может приводить к проблемам", а постом ранее — "с yield никаких проблем нету" Как это нужно понять?
Это не нужно понимать. Я сначала подумал про IEnumerator, для него проблема в состоянии и ленивость ему не прицепишь. У yield (и Linq) таких проблем нет, но есть проблема в отсутствии запоминания.

Здравствуйте, gandjustas, Вы писали:

G>Это не нужно понимать. Я сначала подумал про IEnumerator, для него проблема в состоянии и ленивость ему не прицепишь.

А как к этому следует относиться?

G>У yield (и Linq) таких проблем нет, но есть проблема в отсутствии запоминания.

Ну так я с самого начала и спрашивал. Если "запоминания" нету, значит нужно быть очень осторожным. Об этом было написано тут

Автор: gandjustas
Дата: 25.10.10

. Получается и к yield нужно быть таким же осторожным, верно

Автор: _FRED_
Дата: 25.10.10

: "ленивости для них быть не должно в принципе"?

А зачем тогда нужен yield return тогда (в существующей реализации без запоминания)? Затем же, зачем и goto? Если к его результатам нужно относиться осторожно, то зачем напрягаться?

Здравствуйте, _FRED_, Вы писали:

G>>У yield (и Linq) таких проблем нет, но есть проблема в отсутствии запоминания.

_FR>Ну так я с самого начала и спрашивал. Если "запоминания" нету, значит нужно быть очень осторожным. Об этом было написано тут

Автор: gandjustas
Дата: 25.10.10

. Получается и к yield нужно быть таким же осторожным, верно

Автор: _FRED_
Дата: 25.10.10

: "ленивости для них быть не должно в принципе"?

_FR>А зачем тогда нужен yield return тогда (в существующей реализации без запоминания)? Затем же, зачем и goto? Если к его результатам нужно относиться осторожно, то зачем напрягаться?

Вообще ниче не понял. Ты что сказать хочешь?

Здравствуйте, Аноним, Вы писали:

А>Приведите пожалуйста пример в каком практическом случае эффективно использовать ленивое вычисление.
В тех случаях, когда тебе нужен потенциально бесконечный источник данных.
В конкретной задаче бесконечных переборов не бывает. Но бывают конкретные задачи, построенные из абстрактных кирпичей.
И вот в этих абстрактных кирпичах бывает удобно иметь бесконечные последовательности (или, к примеру, деревья).
Например, можно написать функцию Fibonacci(), которая будет возвращать IEnumerable<int>, и работать с ней при анализе ряда Фибоначчи. Понятно, что обращение Fibonacci().ToArray() гарантированно упадёт; но в практических случаях перебор ограничивается где-нибудь ещё. И это заведомо удобнее, чем писать функцию Fibonacci(length), которая возвращает массив заданной длины — в приложении может потребоваться остановить алгоритм по каким-то другим критериям.

Примеры типа Fibonacci выглядят не очень убедительно потому, что код самой функции очень маленький, и кажется что всегда можно вставить его по месту использования. Но в жизни могут встретиться значительно более интересные случаи, в которых повторное использование будет более важным.

Здравствуйте, gandjustas, Вы писали:

G>>>У yield (и Linq) таких проблем нет, но есть проблема в отсутствии запоминания.
_FR>>Ну так я с самого начала и спрашивал. Если "запоминания" нету, значит нужно быть очень осторожным. Об этом было написано тут

Автор: gandjustas
Дата: 25.10.10

. Получается и к yield нужно быть таким же осторожным, верно

Автор: _FRED_
Дата: 25.10.10

: "ленивости для них быть не должно в принципе"?
_FR>>А зачем тогда нужен yield return тогда (в существующей реализации без запоминания)? Затем же, зачем и goto? Если к его результатам нужно относиться осторожно, то зачем напрягаться?

G>Вообще ниче не понял.

"А зачем тогда нужен yield return"? — что тут не понятного? "тогда" означает "если <Ленивость должна быть с запоминанием>".

G>Ты что сказать хочешь?

Я хочу сказать, что из того, что

Ленивость должна быть с запоминанием

следует, что yield return быть не должно (ибо yield return — это ленивость без запоминания). Но следующие ответы ставят под сомнение этот вывод. Так может быть, предпосылка не верна?

Tom>>1. Не известен момент в который будет произведено вычисление
G>Зачем? Оно ведь может быть и не произведено.
Так и не ленивое может быть не произведено.
Надо — вычисляй, не надо — не вычисляй.
Зачем делать нечто странное под названием ленивое

Tom>>2. Не известен поток
Tom>>3. Не известен call stack
G>Более того, ленивое вычисление может вообще не процессором выполняться.
Может, наверное так же как и не ленивое...

Tom>>4. При возникновении ошибки невозможно предсказать поведение системы
G>При отсутствии сайд-эффектов с точки зрения программы предсказать поведение вполне можно, так как ошибка может быть выкинута по месту обращения.
Как можно предсказать поведение если call stack не известен?

Tom>>Ну и KISS ленивые вычисления явно нарушают.
G>Как раз наоборот. См аппликативный и нормальный порядок редукции.
Давай раз уже пользуешься терминами — определение их.

Tom>>В общем если вдруг вам нужны ленивые вычисления — нужно 10 раз подумать почему. Почему вы не можете явно их выполнить в вполне детерминированные момент времени.
G>Я бы сказал наоборот. Лучше использовать ленивые, пока вам однозначно не станут нужны энергичные вычисления.
А я бы сказал ровно наоборот.

G>Есть целых три НО:
G>1)Должна быть поддержка языка для ленивых вычислений (в C# её фактически нет), кроме Linq
G>2)Должны отсутствовать наблюдаемые сайд-эффекты в вычислениях
G>3)Ленивость должна быть с запоминанием, те если ленивое выражение было вычислено, но оно не должно вычисляться второй раз
Как всё сложно И после этого ты будешь говорить что ленивые вычисления — более правильная парадигма чем "энергичные"?

G>В C# всех трех условий нету, поэтому к ленивости надо относиться осторожно.
С этим полностью согласен

Вообще всё мной описанное относится исключительно к C#, разговор про функциональные языки мы тут не ведём, о них отдельная пестня

Здравствуйте, Sinclair, Вы писали:

Согласен, но это лишь один случай, хоть и довольно распространенный. Кстати, мои любимые VirtualAloc и memory-mapped files есть как раз иллюстрация этого случая. Заказ потенциально бесконечного пространства с тем, чтобы потом использовать, скорее всего, лишь небольшую часть.

Но есть и другой случай. Ситуация, когда попросту непонятно, надо что-то делать или нет.

Вот пример из моей практики. Двоичное дерево, к элементам которого надо было организовать еще и прямой доступ совсем по иному критерию. Завел массив указателей на элементы.

Дерево бурно строится в начале операции. Потом к нему редко могут добавляться элементы. Удаление элементов не предусмотрено, в конце операции дерево уничтожается целиком.

Ясно, что при добавлении элемента массив указателей надо переделывать. А стоит ли ? Вдруг после этого опять потребуется добавить, зачем же, спрашивается, я его переделывал ? А если не придется добавлять, а массив потребуется ?

Я массив отправил в ленивое вычисление, проще говоря, уничтожил его после добавления, присвоил указателю на него NULL и так оставил. Добавят еще раз — на здоровье. А вот когда потребуется прямой доступ — тогда он и будет перевычислен, так как произойдет обращение к нему при NULL, и он будет перевычислен.

Плюс — не делается лишняя работа (то есть не пересоздается массив на каждый чих)
Минус — когда массив понадобится, потребуется время на его вычисление.

У меня плюс перевешивал минус. Может быть наоборот.

Здравствуйте, Tom, Вы писали:

Tom>>>1. Не известен момент в который будет произведено вычисление
G>>Зачем? Оно ведь может быть и не произведено.
Tom>Так и не ленивое может быть не произведено.
Tom>Надо — вычисляй, не надо — не вычисляй.
Tom>Зачем делать нечто странное под названием ленивое
Ленивое может быть вычислено настолько, насколько необходимо для продолжения внешних вычислений.

Tom>>>2. Не известен поток
Tom>>>3. Не известен call stack
G>>Более того, ленивое вычисление может вообще не процессором выполняться.
Tom>Может, наверное так же как и не ленивое...
Но тогда у рантайма нет возможности соптимизировать вычисления (например батчить).

Tom>>>4. При возникновении ошибки невозможно предсказать поведение системы
G>>При отсутствии сайд-эффектов с точки зрения программы предсказать поведение вполне можно, так как ошибка может быть выкинута по месту обращения.
Tom>Как можно предсказать поведение если call stack не известен?
А в чем проблема неизвестности callstack? Как таковой стек вызовов может отсутствовать в программе при активном использовании асинхронности.

Tom>>>Ну и KISS ленивые вычисления явно нарушают.
G>>Как раз наоборот. См аппликативный и нормальный порядок редукции.
Tom>Давай раз уже пользуешься терминами — определение их.
Нормальный порядок редукции — раскрытие сначала внешних термов, аппликативный — раскрытие внутренних.
Нормальных порядок редукции соответствует ленивым вычислениям, аппликативный — энергичным.
Есть теорема, которая говорит что если выражение может быть редуцировано (вычислено) хоть как-нибудь, то оно может быть вычислено используя нормальный порядок редукции.

Tom>>>В общем если вдруг вам нужны ленивые вычисления — нужно 10 раз подумать почему. Почему вы не можете явно их выполнить в вполне детерминированные момент времени.
G>>Я бы сказал наоборот. Лучше использовать ленивые, пока вам однозначно не станут нужны энергичные вычисления.
Tom>А я бы сказал ровно наоборот.

G>>Есть целых три НО:
G>>1)Должна быть поддержка языка для ленивых вычислений (в C# её фактически нет), кроме Linq
G>>2)Должны отсутствовать наблюдаемые сайд-эффекты в вычислениях
G>>3)Ленивость должна быть с запоминанием, те если ленивое выражение было вычислено, но оно не должно вычисляться второй раз
Tom>Как всё сложно И после этого ты будешь говорить что ленивые вычисления — более правильная парадигма чем "энергичные"?
В "правильных" языках — да. В C# — неочень.

G>>В C# всех трех условий нету, поэтому к ленивости надо относиться осторожно.
Tom>С этим полностью согласен

Tom>Вообще всё мной описанное относится исключительно к C#, разговор про функциональные языки мы тут не ведём, о них отдельная пестня
Ну так ты сформулировал претензии безотносительно языка.

G>Ленивое может быть вычислено настолько, насколько необходимо для продолжения внешних вычислений.
Это только ленивое вычисление может быть сделано настолько насколько это надо для продолжения вычислений?

Tom>>Может, наверное так же как и не ленивое...
G>Но тогда у рантайма нет возможности соптимизировать вычисления (например батчить).
Ммммм, отчасти соглашусь. Но всё таки не надо забывать о том что преждевременная оптимизация...
ну и батчить в зависимости от ситуации можно самому.
Например используя паттерн Command.

Tom>>Как можно предсказать поведение если call stack не известен?
G>А в чем проблема неизвестности callstack? Как таковой стек вызовов может отсутствовать в программе при активном использовании асинхронности.
Стек отсуствовать
А проблема простая, у callstack-а есть контекст. Например могут быть определены переменные, некоторые например могут быть ThreadStatic, может присуствовать какой то TransactionScope, у потоков могут быть различные Apartment Model, выполнение может происходить при наличии различных блокировок. Всё это может привести к непредсказуемым результатам выполнения.

Tom>>Как всё сложно И после этого ты будешь говорить что ленивые вычисления — более правильная парадигма чем "энергичные"?
G>В "правильных" языках — да. В C# — неочень.
В правильных языках side эффекты невозможны?

G>>>В C# всех трех условий нету, поэтому к ленивости надо относиться осторожно.
Tom>>С этим полностью согласен

Tom>>Вообще всё мной описанное относится исключительно к C#, разговор про функциональные языки мы тут не ведём, о них отдельная пестня
G>Ну так ты сформулировал претензии безотносительно языка.
В данном форуме C# — дефолтный язык

Здравствуйте, Tom, Вы писали:

G>>Ленивое может быть вычислено настолько, насколько необходимо для продолжения внешних вычислений.
Tom>Это только ленивое вычисление может быть сделано настолько насколько это надо для продолжения вычислений?
Да, для энергичных вычислений ты сам должен ограничивать глубину. В языке с ленивостью можно построить дерево решений, а потом бегать по нему отсекая ненужные ветки.

Tom>>>Как можно предсказать поведение если call stack не известен?
G>>А в чем проблема неизвестности callstack? Как таковой стек вызовов может отсутствовать в программе при активном использовании асинхронности.
Tom>Стек отсуствовать
Tom>А проблема простая, у callstack-а есть контекст. Например могут быть определены переменные, некоторые например могут быть ThreadStatic, может присуствовать какой то TransactionScope, у потоков могут быть различные Apartment Model, выполнение может происходить при наличии различных блокировок. Всё это может привести к непредсказуемым результатам выполнения.
Если вычисления функционально чисты, то нет. А ленивость с сайд-эффектами плохо сочетается, это всем вроде бы известно.

Tom>>>Как всё сложно И после этого ты будешь говорить что ленивые вычисления — более правильная парадигма чем "энергичные"?
G>>В "правильных" языках — да. В C# — неочень.
Tom>В правильных языках side эффекты невозможны?
Возможны, но они присутствуют там явно.

Здравствуйте, Аноним, Вы писали:

А>Приведите пожалуйста пример в каком практическом случае эффективно использовать ленивое вычисление.

Наиболее полезное использование ленивого вычисления этого автоматический кэш, который при обращении к нему проверяет изменились ли входы и если изменились, то пересчитывает значение, иначе возвращает кэшированное. Проблемы связанные с рассинхронизацией благодаря этому решению исчезают в принципе.

Здравствуйте, dilmah, Вы писали:

А>>Приведите пожалуйста пример в каком практическом случае эффективно использовать ленивое вычисление.

D>практическая польза в том, что ты можешь писать более простой и понятный код, не волнуясь об оптимизации, зная что она произойдет автоматически.
1. Ага будет очень понятно когда при обращению к проперти из ГУИ получишь какой-нибудь socket exception
2. Можно наоборот получить сильно неоптимальный код

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, Аноним, Вы писали:

А>>Приведите пожалуйста пример в каком практическом случае эффективно использовать ленивое вычисление.

U>Наиболее полезное использование ленивого вычисления этого автоматический кэш, который при обращении к нему проверяет изменились ли входы и если изменились, то пересчитывает значение, иначе возвращает кэшированное. Проблемы связанные с рассинхронизацией благодаря этому решению исчезают в принципе.

Можно пример в виде кода , не совсем понятно что значит кэш коллекции и то что ее состояние не изменилось ? Откуда оно узнает о том что состояние объекта не менялось ,?

Здравствуйте, gandjustas, Вы писали:

G>Это вообще говоря фигня. Ленивость позволяет наиболее просто записывать многие алгоритмы.
G>Например можно построить дерево решений, полное дерево решений, оно все равно ленивое и реально будет отсутствовать в памяти, а потом методом ветвей и границ отсекать ненужные решения.

То есть ленивость — это по сути есть оптимизация. Если производительность нас устраивает, то ленивость нафиг не нужна. Если же производительность не устраивает, то ленивость — это один из способов оптимизации, который, как и любая другая оптимизация, усложняет оригинальное (то есть без оптимизаций) решение. Короче говоря, тут работают все остальные широко известные правила применения оптимизаций.

Здравствуйте, mrTwister, Вы писали:

T>Здравствуйте, gandjustas, Вы писали:

G>>Это вообще говоря фигня. Ленивость позволяет наиболее просто записывать многие алгоритмы.
G>>Например можно построить дерево решений, полное дерево решений, оно все равно ленивое и реально будет отсутствовать в памяти, а потом методом ветвей и границ отсекать ненужные решения.

T>То есть ленивость — это по сути есть оптимизация.
Наоборот, энергичность — оптимизация.

T>Если производительность нас устраивает, то ленивость нафиг не нужна.
То есть энергичные вычисления не нужны.

T>Если же производительность не устраивает, то ленивость — это один из способов оптимизации, который, как и любая другая оптимизация, усложняет оригинальное (то есть без оптимизаций) решение. Короче говоря, тут работают все остальные широко известные правила применения оптимизаций.
Ты сделал неправильную посылку. Поменяй в своем сообщении ленивость на энергичность, так будет правильнее, и посмеемся вместе.

Здравствуйте, Аноним, Вы писали:

А>Можно пример в виде кода , не совсем понятно что значит кэш коллекции и то что ее состояние не изменилось ? Откуда оно узнает о том что состояние объекта не менялось ,?

Простейший пример:

    readonly RawCache<Bitmap> mapImageCache;
    Bitmap mapImage
    {
      get { return mapImageCache.Result; }
    }

    public MapImage(IMapModule mapModule)
    {
      this.mapImageCache = new Cache<Bitmap, Size>(
        delegate(Size imageSize)
        {
          return DrawingHlp.SafeCreateBitmap(imageSize.Width, imageSize.Height);
        },
        delegate { return mapPainter.ClientBounds.Size; }
      );
    }

При вызове mapImage кэш проверяет совпадает ли текущее значение второго делегата (ClientBounds.Size) с запомненным, если да, то возвращает запомненное изображение, если нет, то вызывает первый делегат и изображение пересоздает.

Здравствуйте, gandjustas, Вы писали:

T>>То есть ленивость — это по сути есть оптимизация.
G>Наоборот, энергичность — оптимизация.

С чего это вдруг? При использовании ленивости мы откладываем вычисления на максимальный срок с надеждой, что эти вычисления вообще никогда не будут выполнены. Это и есть оптимизация. Проблема здесь в том, что проявление возможных ошибок также откладывается на максимальный срок, что усложняет тестирование, обнаружение и расследование ошибок.

T>>Если производительность нас устраивает, то ленивость нафиг не нужна.
G>То есть энергичные вычисления не нужны.
Нет, энергичные вычисления проще и надежнее, но могут быть проблемы с ресурсами.