Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[35.175.200.199] |
|
Страницы: (16) « Первая ... 12 13 [14] 15 16 все ( Перейти к последнему сообщению ) |
Сообщ.
#196
,
|
|
|
Цитата Исмаил Прокопенко @ Flex FerrumПо крайней мере инженер отдаёт себе отчёт, что "при данной метОде решения задачи возможен фак ап". А программист просто "закрывает глаза" и врёт даже себе Добавлено Не говоря уже про коллег на форуме Ну да! Программист же - он тупой, к любой задаче с одним инструментом подходит, а потом возмущается, почему для программирования какого-нибудь S7-300 ему только FBD предлагают, а на С++17 - нельзя. Или почему при разработке числодробилки под айбиэмовский DeepBlue у него такой адовый шит в коде получается. Угу. Нет, чтобы докумекать, что в S7-300 - жёсткий реалтайм, а на машинке, где число процессоров измеряется тысячами, синхронизация потоков - очень дорогая штука. Ну идиот, одно слово. |
Сообщ.
#197
,
|
|
|
Цитата Исмаил Прокопенко @ Инженер считает, что число пи равно 3, а если нужно точно, то 3.14.Инженер считает, что проект не сделан, если факап возможен хотя бы чисто теоретически, а программист, если вероятность факапа мала, считает, что он невозможен и считает, что свою задачу он выполнил А знающий программист знает, что там дальше ещё много много цифр. Инженерам обычно хватает приближённых эмпирических формул, и они сильно удивляются, когда подсунув эти грубые формулы программисту, получает в ответ сильно приближённое решение. Ведь формулы-то точные. |
Сообщ.
#198
,
|
|
|
Цитата Исмаил Прокопенко @ Это квантовая механика. Один в один. Мы в матрице. "Самый очевидный плюс ленивых вычислений — если что-то не требуется, оно не будет вычислено." Добавлено Исмаил Прокопенко, тебе ещё не надело клоуном работать? |
Сообщ.
#199
,
|
|
|
Цитата Flex Ferrum @ Программист же - он тупой Но согласитесь, что лавинообразный рост вычислительной нагрузки возможен, а Вы говорите, что нет. Хотя любому инженеру это очевидно. Достаточно написать 3 строчки C=f3(e,f,g) B=f1(C,D) А=B*C Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих. А если бы строчек было 10? А если каждая функция имеет по 5 параметров и внутри вызывает кучу других функций? Уже разрулить "завязки" (т.е. что с чем связано, а значит, что нужно считать "прям щас", а что можно отложить) уже нетривиальная задача, жрущая не малые ресурсы. А тут ещё лавина отложенных вычислений, которые все откладывались, откладывались и вот наконец пришло время их выполнять |
Сообщ.
#200
,
|
|
|
Цитата D_KEY @ В какой-то степени да, синтаксический сахар. Но дык, например, синтаксис лямбд в С++ тоже не более, чем синтаксический сахар. Тебе они тоже не слишком интересны?Фактически он и создается. Если тебя привлекает синтаксический сахар, то мне этот разговор будет не слишком интересен Цитата D_KEY @ Не понятно, как именно ты собрался его уничтожать. Что ты имеешь в виду? Уничтожение в другом потоке?Кстати, что будет, если в выражении указать объект, который будет уничтожен до реального вычисления? Я к тому, что из вызова не видно, что выражение будет вычислено лениво. Цитата D_KEY @ Не знаю, мне даже думать на эту тему не хочется. Наверное также как и в случае неленивых параметров. Я ленивость вызова функций не считаю архиполезной штукой, использую редко и как правило в простых случаях. А Perfect Forwarding сам по себе отрыжка академического плюсового перфекционизма. Эта неуёмная жажда обобщить все на свете на практике только вредит.И еще такой вопрос, в обобщенном коде как мне сделать perfect forwarding в случае ленивых параметров? Цитата Исмаил Прокопенко @ Поэтому мы видим вокруг тонны инженерного факапа. И опять всплывает разница между программистами и инженерами. Инженер считает, что проект не сделан, если факап возможен хотя бы чисто теоретически, а программист, если вероятность факапа мала, считает, что он невозможен и считает, что свою задачу он выполнил |
Сообщ.
#201
,
|
|
|
Цитата applegame @ Цитата D_KEY @ В какой-то степени да, синтаксический сахар. Но дык, например, синтаксис лямбд в С++ тоже не более, чем синтаксический сахар. Тебе они тоже не слишком интересны?Фактически он и создается. Если тебя привлекает синтаксический сахар, то мне этот разговор будет не слишком интересен Не слишком. Но код упрощают во многих случаях, да. Цитата Цитата D_KEY @ Не понятно, как именно ты собрался его уничтожать. Что ты имеешь в виду? Уничтожение в другом потоке?Кстати, что будет, если в выражении указать объект, который будет уничтожен до реального вычисления? Я к тому, что из вызова не видно, что выражение будет вычислено лениво. Ну я же могу сохранить этот параметр, не потеряв ленивость? Вот сохранил я его, а объекты, которые используются в выражении давно уничтожены. Что произойдет? Цитата А Perfect Forwarding сам по себе отрыжка академического плюсового перфекционизма. Эта неуёмная жажда обобщить все на свете на практике только вредит. |
Сообщ.
#202
,
|
|
|
Цитата applegame @ Поэтому мы видим вокруг тонны инженерного факапа. Потому что инженерный фак ап лежит на поверхности, поэтому и кажется что его много. Хотя на самом деле у программистов фак апа в разы больше, просто он глубоко зарыт Добавлено И потом, исправить косяк в железе - это тебе не пару строк в коде поправить. На это иногда ГОДЫ нужны и огромные ресурсы |
Сообщ.
#203
,
|
|
|
Цитата D_KEY @ Здесь то же самое, код может упростить, но не является серебряной пулей. Просили пример где lazy полезно, я его привел. Хочешь синтаксическим сахаром, хочешь костылями.Не слишком. Но код упрощают во многих случаях, да. Цитата Исмаил Прокопенко @ И что? В третьей строчке фактически будет вычислены первая и вторая. Итоговое время выполнения не изменится вообще никак. Да и итоговый машинный код будет одинаковым.Достаточно написать 3 строчки C=f3(e,f,g) B=f1(C,D) А=B*C Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих. Ты наверное никогда не пишешь a = (b + c) * d + e / f; это же ЛАВИННОСТЬ!!! надо писать bc = b + c; bc = bc * d; ef = e / f; a = bc + ef; Так-скаать "размазать" код по строчкам, для более плавного выполнения. |
Сообщ.
#204
,
|
|
|
Цитата applegame @ И что? В третьей строчке фактически будет вычислены первая и вторая. Итоговое время выполнения не изменится вообще никак. Да и итоговый машинный код будет одинаковым. Не верно. Во первых если значения некоторых переменных вычислить заранее, то память под уже не нужные переменные можно освободить. А в случае лавины потребуется сразу вся память, так как придется "держать в уме" сразу все переменные. А во вторых, как я понимаю, в случае "ленивых языков" компилятор вместо вставки уже вычисленного ранее значения вставляет некий "код пролога" (например вызов функции), который вычислит это значение. Т.е. некоторую ссылку на код, который формирует нужное значение. |
Сообщ.
#205
,
|
|
|
"Лавины" действительно могут быть, я выше писал об этом. Возможно, это следствие кривых рук и неумения использовать haskell, но тем не менее.
|
Сообщ.
#206
,
|
|
|
Цитата D_KEY @ это следствие кривых рук и неумения использовать haskell Так с прямыми руками и хаскелл с его ленивыми вычислениями не нужен. Так? Хороший программист и так пишет программу так, чтобы она наиболее оптимально работала и использовала ресурсы. А все эти "ленивые вычисления" и прочие костыли - это просто средства защиты от криворуких программистов. Так? Добавлено Ведь не секрет, что 99% программистов имеют, мягко говоря, неудовлетворительную квалификацию и интеллект. Не случайно же у них так "туго идут" общеинженерные дисциплины. Поэтому приходится изощраться и придумывать разные костыли, чтобы даже низкоквалифицированный программист мог хоть какую-то пользу приносить |
Сообщ.
#207
,
|
|
|
Цитата Исмаил Прокопенко @ Да и третья вычисляться не будет. Результат-то пока не нужен.Достаточно написать 3 строчки C=f3(e,f,g) B=f1(C,D) А=B*C Получается, что первые две строчки не будут выполнены пока программа не дойдёт до 3-й и поймет, что ей нужны результаты предыдущих. Реально эти выражения компилируются в дерево операций, как только значение понадобится, оно по этому дереву вычисляется. Ненужные более ветви сразу отсекаются. На практике ты получишь тот же код, что и в обычном императивном языке, разве что порядок вычислений может поменяться. Цитата applegame @ Это не потому, что инженер допускает факап. Это потому, что он не считает его факапом.Поэтому мы видим вокруг тонны инженерного факапа Цитата Исмаил Прокопенко @ А зачем их держать в памяти? Как только все вычисления со значением закончатся, ненужное значение сразу можно чистить. Хранить приходится только именованные переменные, но в функциональных языках они используются нечасто. Вот в императивных языках с этим сложности, там переменных на порядок больше, а без отслеживания времени жизни приходится все переменные держать в активном состоянии. Во первых если значения некоторых переменных вычислить заранее, то память под уже не нужные переменные можно освободить. А в случае лавины потребуется сразу вся память, так как придется "держать в уме" сразу все переменные. |
Сообщ.
#208
,
|
|
|
Исмаил Прокопенко, у вас в посте очень мало конструктивных высказываний. Возможно даже совсем нет.
Добавлено Цитата amk @ А зачем их держать в памяти? Как только все вычисления со значением закончатся, ненужное значение сразу можно чистить. Хранить приходится только именованные переменные, но в функциональных языках они используются нечасто. Проблема в том, что даже ленивые списки часто действительно используются не по делу. Даже в примерах. Там, где в "императоры языках" был бы обычный обход, в функциональщине часто видим списки, которые таки да, сохраняют результат вычислений и держат его в памяти по крайней мере до окончания обхода(хотя в некоторых случаях правильной хвостовой рекурсии предыдущие элементы списка можно будет освободить, но не уверен, что это делается). |
Сообщ.
#209
,
|
|
|
Цитата D_KEY @ Попытка сымитировать состояние (как бы переменные и цикл) при использовании парадигмы, где состояния в принципе быть не должно. Программист просто никак не может отойти от привычной императивщины. в функциональщине часто видим списки, которые таки да, сохраняют результат вычислений и держат его в памяти |
Сообщ.
#210
,
|
|
|
Ой не пойму, об чём вообще спор. От перемены мест вычислений в программе сумма затребованных ими ресурсов не изменится. Это в идеале, в реальности на хранение списков нужны дополнительные ресурсы, но и на вычисления по месту нужны дополнительные ресурсы, и бывает, что больше одних, а бывает, что и других.
Другое дело, что некоторые алгоритмические фрагменты могут перекрывать друг друга, поэтому вычисления по факту требования их результата могут отменить некоторые предшествующие элементы списков, поэтому ленивость является главным образом оптимизацией в рант-тайм, выбрасывающая ранние вычисления, перекрытые последующими. Если архитектура языка ориентирована на отложенные вычисления, то списки априори дёшевы, и проблема лишь в том, чтобы эту архитектуру реализовать на практике. О чём тут ещё спорить-то? |