Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.223.196.171] |
|
Страницы: (16) « Первая ... 8 9 [10] 11 12 ... 15 16 все ( Перейти к последнему сообщению ) |
Сообщ.
#136
,
|
|
|
Например ленивые списки. Зачем обрабатывать весь список, если можно обратотать только ту часть, которая нужна здесь и сейчас?
|
Сообщ.
#137
,
|
|
|
Цитата applegame @ Например ленивые списки. Зачем обрабатывать весь список, если можно обратотать только ту часть, которая нужна здесь и сейчас? Странный пример - а в нефункциональных языках зачем? Что мешает указать диапазон обработки? |
Сообщ.
#138
,
|
|
|
Цитата JoeUser @ Что значит нефункциональных? D - функциональный язык? В стандартной библиотеке полно функций порождающих из одних списков (ranges) другие, зачастую ленивые. Как именно указать диапазон? Допустим список - это поток символов, поступающих из сети. Странный пример - а в нефункциональных языках зачем? Что мешает указать диапазон обработки? Для примера: нам нужно загрузить из сети некий большой json-файл, найти там определенное место и выдрать нужный объект. Неленивый подход: 1. Загрузить целиком json. 2. Распарсить его целиком. 3. Найти нужное место и выдрать нужное. Ленивый подход: 1. Создаем ленивый список входящих символов. 2. Преобразовываем это список в ленивый же список токенов. 3. Лениво обрабатываем список токенов пока не найдем нужное. Ленивый подход требует держать в памяти только текущий обрабатываемый токен, а не весь json и полный список токенов как в неленивом подходе. |
Сообщ.
#139
,
|
|
|
Цитата applegame @ Цитата JoeUser @ Что значит нефункциональных? D - функциональный язык? В стандартной библиотеке полно функций порождающих из одних списков (ranges) другие, зачастую ленивые. Как именно указать диапазон? Допустим список - это поток символов, поступающих из сети. Странный пример - а в нефункциональных языках зачем? Что мешает указать диапазон обработки? Для примера: нам нужно загрузить из сети некий большой json-файл, найти там определенное место и выдрать нужный объект. Неленивый подход: 1. Загрузить целиком json. 2. Распарсить его целиком. 3. Найти нужное место и выдрать нужное. Ленивый подход: 1. Создаем ленивый список входящих символов. 2. Преобразовываем это список в ленивый же список токенов. 3. Лениво обрабатываем список токенов пока не найдем нужное. Ленивый подход требует держать в памяти только текущий обрабатываемый токен, а не весь json и полный список токенов как в неленивом подходе. При чем тут ленивость? Если дело ограничивается токенами и нам не нужен настоящий паркинг json, то это просто последовательное чтение токенов из потока. Или я чего-то не понял? |
Сообщ.
#140
,
|
|
|
applegame, я понял твою мысль. У ленивых (отложенных) вычислений есть и негативная сторона - выполняя вычисления полностью, мы как бы кэшируем результат. И при повторном обращении читаем уже вычисленное. А в случае ленивых вычислений? Должны опять вычислить?
|
Сообщ.
#141
,
|
|
|
Цитата JoeUser @ applegame, я понял твою мысль. У ленивых (отложенных) вычислений есть и негативная сторона - выполняя вычисления полностью, мы как бы кэшируем результат. И при повторном обращении читаем уже вычисленное. А в случае ленивых вычислений? Должны опять вычислить? Цитата Type res = var.a().b().c().d().get() Пока не вызван get() не вычисляется ни результат a(), ни результат b(), c() или d(). Вызвали get() - пошла работать вся цепочка, get() вернул итоговый результат. Кэшируй его сколько угодно. |
Сообщ.
#142
,
|
|
|
Так и перегруженный оператор индекса в С++, по сути, и есть - ленивое вычисление. Но ... каждый раз он вычисляется, при каждом обращении. Это часто знатно снижает быстродействие. Т.к. создание временного массива и весь его просчет один раз - может дать заметный выхлоп, если обращений к одним и тем же элементам - множественное, повторное. Я об этом.
|
Сообщ.
#143
,
|
|
|
Народ, извините, что вмешиваюсь в ваш высокодуховный спор, но вы хотя бы в википедию загляните. А то ваша дискуссия выглядит как обсуждение вкуса омаров людьми, которые в жизни только крабовое мясо-суррогат ели.
|
Сообщ.
#144
,
|
|
|
Ну я тут вот почитал. Понятное дело, без практики - приходится крабовое мясо обсуждать
|
Сообщ.
#145
,
|
|
|
Цитата D_KEY @ Ну может быть пример не совсем удачный.При чем тут ленивость? Если дело ограничивается токенами и нам не нужен настоящий паркинг json, то это просто последовательное чтение токенов из потока. Или я чего-то не понял? Попробую по-другому. В D есть функция map, которая применяет некую функцию ко всем элементам списка (range) и возвращает список (опять же range) с результатами применения этой функции. map - это шаблонная функция, она кушает списки любого вида в том числе и обычные массивы. Если ей подсунуть массив, то она вернет список, который ведет себя тоже как массив (доступ по индексу, слайсы и т.д, в дешной терминологии это RandomAccessRange). Но при это она реально не вычисляет ничего. Вычислению будут происходить только при непосредственном обращении к элементам. Это и есть ленивый список. В дешной стандартной либе полно всяких трансформирующих функций для работы со списками, многие из них никаких вычислений не делают, а сразу же возвращают результат - ленивый список. Другой пример (извините, опять D ): string heavyFun() { ... } foo(flag, heavyFun()); // функция heavyFun не будет вычислена в этой точке void foo(bool flag, lazy string txt) { if(flag) writeln(txt); // она будет вычислена в этой точке и только если flag - истина } |
Сообщ.
#146
,
|
|
|
applegame, разве ты сейчас не потерял контекст и от примера полезного использования не перешел к тривиальному объяснению?
|
Сообщ.
#147
,
|
|
|
Цитата D_KEY @ А чем этот пример не годится? Функция рассчитывается только когда нужно, а не при каждом вызове. Разве это не профит? applegame, разве ты сейчас не потерял контекст и от примера полезного использования не перешел к тривиальному объяснению? |
Сообщ.
#148
,
|
|
|
Цитата applegame @ Цитата D_KEY @ А чем этот пример не годится? Функция рассчитывается только когда нужно, а не при каждом вызове. Разве это не профит?applegame, разве ты сейчас не потерял контекст и от примера полезного использования не перешел к тривиальному объяснению? Само по себе нет |
Сообщ.
#149
,
|
|
|
Цитата applegame @ Цитата D_KEY @ Ну может быть пример не совсем удачный.При чем тут ленивость? Если дело ограничивается токенами и нам не нужен настоящий паркинг json, то это просто последовательное чтение токенов из потока. Или я чего-то не понял? Попробую по-другому. В D есть функция map, которая применяет некую функцию ко всем элементам списка (range) и возвращает список (опять же range) с результатами применения этой функции. map - это шаблонная функция, она кушает списки любого вида в том числе и обычные массивы. Если ей подсунуть массив, то она вернет список, который ведет себя тоже как массив (доступ по индексу, слайсы и т.д, в дешной терминологии это RandomAccessRange). Но при это она реально не вычисляет ничего. Вычислению будут происходить только при непосредственном обращении к элементам. Это и есть ленивый список. В дешной стандартной либе полно всяких трансформирующих функций для работы со списками, многие из них никаких вычислений не делают, а сразу же возвращают результат - ленивый список. Другой пример (извините, опять D ): string heavyFun() { ... } foo(flag, heavyFun()); // функция heavyFun не будет вычислена в этой точке void foo(bool flag, lazy string txt) { if(flag) writeln(txt); // она будет вычислена в этой точке и только если flag - истина } Все что Вы описали мне кажется называется не "ленивые вычисления", а "оптимизация", когда часть компилятора, называемая "оптимизатор" анализируя зависимости выбрасывает неиспользуемый код. |
Сообщ.
#150
,
|
|
|
Вот здесь
Очень хорошее описание - что можно назвать так называемыми "ленивыми вычислениями." Исчерпывающе |