Функциональное програмирование , Что за зверь такой

Цитата Flex Ferrum @ 17.03.17, 07:00

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

Так толстый же. И унылый. До Мастерова, как до Китая!

Добавлено 17.03.17, 07:11
В восьмой жабе, если уж говорить про ленивость, сделали стримы, которые насквозь ленивые, да еще туда возможность не явной параллельности впихнули Оч круто!

Цитата applegame @ 17.03.17, 06:54

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

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

Добавлено 17.03.17, 07:15

Цитата applegame @ 17.03.17, 06:54

Цитата D_KEY @ 16.03.17, 22:05

В плюсах, кстати lazy<T> вроде несложно делается.

Очень сомневаюсь. Но было бы интересно посмотреть на такое. Давай ссылку или сам набросай.

А что там сложного? Делаем прокси-объект, который вызывает при обращении функцию для вычисления значения и умеет кэшировать результат.

А еще есть std::async и std::launch::deferred. Я правда не юзал никогда, но тоже можно попробовать

Если что - мой вариант ленивых списков здесь. Примеры использования можно найти в тестах.

Добавлено 17.03.17, 08:43
Кстати, принципиальное отличие от range'ей из N4128 - это то, что ты можешь вернуть такой список. То есть отличие примерно такое же, как между std::function<> и лямбдой.

Цитата D_KEY @ 17.03.17, 07:13

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

lazy и мемоизация - перпендикулярные вещи. Кеширование можно делать, если функция чистая. Но не обязательно.

Цитата D_KEY @ 17.03.17, 07:13

А что там сложного? Делаем прокси-объект, который вызывает при обращении функцию для вычисления значения и умеет кэшировать результат.

То есть на вызывающей стороне, мне придется создавать этот прокси объект? Весь прикол как раз в том, что и для вызывающей стороны и для вызываемой функции lazy-параметр выглядит как обычная переменная, а не как прокси-объект, который нужно создавать, а потом вытаскивать из него результат вычислений. Получится костыль, а не lazy.

Добавлено 17.03.17, 08:48

Цитата D_KEY @ 17.03.17, 08:31

А еще есть std::async и std::launch::deferred. Я правда не юзал никогда, но тоже можно попробовать

Я юзал, но не в контексте lazy, а в многопоточном окружении, для которого они и предназначены.

Сообщение отредактировано: applegame - 17.03.17, 08:48

Цитата Астарот @ 17.03.17, 06:00

Есть мнение, что ленивые вычисления не столько экономят проц, сколько ускоряют работу программы. По крайней мере я бы искал профит именно в этом.

И каким образом они это делают? Да, как правило, использование ленивых вычислений позволяет избежать вычисления ненужных значений.
Но иногда удаётся и воспользоваться оптимизацией при вычислении. Например, если надо перемножить несколько матриц разного размера, то используя сочетательный закон можно поменять трудоёмкость вычислений на порядки. Более того, прямой порядок вычислений может оказаться вообще невозможным.

Добавлено 17.03.17, 09:21
Вообще для ускорения работы программы существует два противоположных подхода. Один - отложить вычисления «на потом», второй - выполнить вычисления заранее. Иногда срабатывает один, иногда другой. Иногда оба не работают.

Цитата amk @ 17.03.17, 09:18

И каким образом они это делают?

Ну, как каким? Если из всего множества ленивых вычислений будет сделано только одно, которое нужно, то вот тебе и ускорение - мы не потратили время на лишние расчеты Таким образом чисто на уровне бизнес-логики твоего приложения ты можешь заранее готовить любое количество вычислений, а время потратить только на одно в самый последний момент.

Цитата amk @ 17.03.17, 09:18

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

А распараллелить это какой из них?

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

Цитата amk @ 17.03.17, 11:54

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

Это сразу оба, потому что начинаешь вычислять заранее, а результат получишь где-то потом

Цитата applegame @ 17.03.17, 08:46

Цитата D_KEY @ 17.03.17, 07:13

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

lazy и мемоизация - перпендикулярные вещи. Кеширование можно делать, если функция чистая. Но не обязательно.

Я про условную реализацию lazy. Фактически это функциональный объект + мемоизация.

Цитата

То есть на вызывающей стороне, мне придется создавать этот прокси объект? Весь прикол как раз в том, что и для вызывающей стороны и для вызываемой функции lazy-параметр выглядит как обычная переменная

Фактически он и создается. Если тебя привлекает синтаксический сахар, то мне этот разговор будет не слишком интересен
Можно решить за счет шаблонов выражений, макросов и др. костылей=)

Кстати, что будет, если в выражении указать объект, который будет уничтожен до реального вычисления?
Я к тому, что из вызова не видно, что выражение будет вычислено лениво.
И еще такой вопрос, в обобщенном коде как мне сделать perfect forwarding в случае ленивых параметров?

Цитата Flex Ferrum @ 17.03.17, 06:45

Нет. Не так. В программе описывается правило получение некоего результата (в виде функции), эта функция переносится в рантайм и вызывается только тогда, когда результат действительно необходим. Если такой необходимости не возникло - функция не вызывается. Всё, вроде, просто. Обычно используется в связке с операциями над списками и функциями второго порядка, но не всегда.

Т.е. Вы даже теоритечески не видите возможности возникнровения ЛАВИНЫ, которая может обружить всю систему?
Нет. Все таки не зря я создал тему "все программисты ...."
Вы не инженеры, Вы мистики.

Вы верите и надеетесь.
А инженер ЗНАЕТ

Добавлено 17.03.17, 15:47

Цитата amk @ 17.03.17, 09:18

Цитата amk @ 17.03.17, 09:18

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

Есть ещё третий подход (ИМХО самый правильный): запомнить значение уже ранее вычислявшееся, и потом повторно уже не вычислять его, а тупо достать его из хэш таблицы

Сообщение отредактировано: Исмаил Прокопенко - 17.03.17, 15:48

Цитата Исмаил Прокопенко @ 17.03.17, 15:43

Т.е. Вы даже теоритечески не видите возможности возникнровения ЛАВИНЫ, которая может обружить всю систему?

Чисто теоретически я могу видеть всё, что угодно. Хоть ЛММ, хоть Ктулху, хоть пса пятиногого. А практически - всё зависит от аппаратного и программного окружения. Но это ведь такие мелочи, правда?

Цитата Flex Ferrum @ 17.03.17, 15:48

Чисто теоретически я могу видеть всё, что угодно. Хоть ЛММ, хоть Ктулху, хоть пса пятиногого. А практически - всё зависит от аппаратного и программного окружения.

Опять незачот.
Все зависит от программы, а не программного окружения.

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

Сообщение отредактировано: Исмаил Прокопенко - 17.03.17, 15:52

Цитата Исмаил Прокопенко @ 17.03.17, 15:50

Инженер не допускает факапа даже теоретически

Гы-гы

Flex FerrumПо крайней мере инженер отдаёт себе отчёт, что "при данной метОде решения задачи возможен фак ап".

А программист просто "закрывает глаза" и врёт даже себе

Добавлено 17.03.17, 16:17
Не говоря уже про коллег на форуме