Здравствуйте, gandjustas, Вы писали:
G>Ну например ему может понадобится найти максимальную из четных сумм, которые меньше заданного числа...
И что ? В том массиве, что я сделал, ее найти нельзя ? Кстати, если уж именно это надо — оборву цикл, как найду первую сумму, которая больше заданного, ибо дальше будет еще больше . И для этой задачи и массив-то совсем не нужен. Ни один. Суммируй в одну переменную пока сумма >= заданного не станет, и отмечай максимальную из четных.
G>или еще как-то скомбинировать результирующую последовательность с другими операциями.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Пельмешко, Вы писали:
П>>Не знаю Чисто академический интерес, наверное, или любовь к декларативности П>>Разве это не прекрасно? П>>
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>или еще как-то скомбинировать результирующую последовательность с другими операциями.
PD>Кто мешает ?
удобство То, что Вы напишете императивными циклами с прыжками и несколькими уровнями вложенности будет намного сложнее читать и анализировать, чем пару декларативных строчек на linq \ любом ФЯ.
array[0] = 0;
for (int i = 1; i < size; i++)
array[i] = array[i - 1] + i;
t ≈ 80 символов ∕ v символов/секунда
При том, что первый способ проще для восприятия, так как оперирует коллекциями, а не их элементами. (Это как в математике — инвариантная запись формулы предпочтительнее покоординатной-в-некотором-базисе.)
Здравствуйте, Пельмешко, Вы писали:
П>Здравствуйте, Pavel Dvorkin, Вы писали:
G>>>или еще как-то скомбинировать результирующую последовательность с другими операциями.
PD>>Кто мешает ?
П>удобство То, что Вы напишете императивными циклами с прыжками
Прыжками — это goto ? С фортрановских времен не писал. Как-нибудь обойдусь.
>и несколькими уровнями вложенности будет намного сложнее читать и анализировать, чем пару декларативных строчек на linq \ любом ФЯ.
Сложнее читать — верно. Кому читать — человеку ? Да.
Сложнее анализировать — верно. Кому анализировать — человеку ? Да.
А работать-то программа должна не в мозгу человека, а в машине!
Кто же за бедную машину-то заступится ? Жалко ее. Столько бессмысленной работы делать!
А если серьезнее — я как-то с трудом себе представляю автозавод, например, руководство которого бы заявило — да, наша машина ездит со скоростью в 5 раз ниже, чем у конкурентов, но зато посмотрите, как легко нашим конструкторам было ее разработать и нашим рабочим собирать! И изменить ее легко, правда, не исключено, что она будет после этого иметь скорость в 10 раз ниже.
И коли в ИТ такой подход не вызывает противодействия — значит, что-то неладно в Датском Королевстве.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Пельмешко, Вы писали:
П>>Разве это не прекрасно? П>>
П>>let sums = { 0 .. n } |> Seq.scan (+) 0
П>>
PD>Прекрасно, но при условии, что это работает на абстрактной машине
Ага, я прям смотрю на это и ужасаюсь:
+ виртуальный вызов на каждое сложение!
+ по два интерфейсных вызова на элемент (а они в .net ух медленные какие, там же практически двойная косвенность)!
+ на аккумулятор аж 4 байта выделяется!
+ статический вызов Seq.scan, аж с тремя аргументами!
+ генератор последовательности на куче создать надо, ужос...
Здравствуйте, Qbit86, Вы писали:
Q>Время работы зависит от скорости. Пусть скорость набора — v, тогда
<skipped>
Объясняю популярно — давай время работы программы, а не машинистки.
Q>При том, что первый способ проще для восприятия, так как оперирует коллекциями, а не их элементами. (Это как в математике — инвариантная запись формулы предпочтительнее покоординатной-в-некотором-базисе.)
Меня не интересует простота восприятия. Сколько времени в мсек этот код работает ? Запусти и приведи результат.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Ну например ему может понадобится найти максимальную из четных сумм, которые меньше заданного числа...
PD>И что ? В том массиве, что я сделал, ее найти нельзя ? Кстати, если уж именно это надо — оборву цикл, как найду первую сумму, которая больше заданного, ибо дальше будет еще больше . И для этой задачи и массив-то совсем не нужен. Ни один. Суммируй в одну переменную пока сумма >= заданного не станет, и отмечай максимальную из четных.
именно этим код со scan и занимается
Только возможностей по композиции у него гораздо больше.
Тебе же придется переписывать большую часть кода при незначительном изменении условий.
G>>или еще как-то скомбинировать результирующую последовательность с другими операциями. PD>Кто мешает ?
Циклы мешают.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Пельмешко, Вы писали:
П>>удобство То, что Вы напишете императивными циклами с прыжками
PD>Прыжками — это goto ? С фортрановских времен не писал. Как-нибудь обойдусь.
Вы упомянули break, которым могли бы раньше выйти из цикла, а он и есть тот же самый прыжок.
ФВП тоже могут остановить цикл прохода по последовательности, тем же break, только это скрыто внутри них, а я не буду думать куда этот break перенесёт поток управления, я просто получу результат.
PD>Кто же за бедную машину-то заступится ? Жалко ее. Столько бессмысленной работы делать!
Это не бессмысленная работа, просто другой способ исполнять ту же работу, просто менее эффективный в силу архитектуры.
PD>И коли в ИТ такой подход не вызывает противодействия — значит, что-то неладно в Датском Королевстве.
Задачи становятся всё сложнее и сложнее, сложность кода возрастает и одними циклами просто уже не обойтись.
Да, самый низ лучше строить на императивных циклах, но задачи чуть выше гораздо удобнее описывать в терминах ФВП.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Объясняю популярно — давай время работы программы, а не машинистки.
У вас в конторе код набирают машинистки под диктовку?
PD>Меня не интересует простота восприятия.
Павел, вы, видимо, не работаете в коллективе?
PD>Сколько времени в мсек этот код работает? Запусти и приведи результат.
Я по-умолчанию предполагаю, что наиболее простой для восприятия код с эквивалентной асимптотикой работает достаточно быстро — пока не доказано обратное. Когда будет доказано — и не в попугаях, а в профилировщике (т.е. с учётом частоты выполнения участка кода) — только тогда и надо думать об оптимизации.
Наш внештатный К.О. с мест докладывает, что всё это уже говорилось на RSDN сотни раз.
Здравствуйте, Пельмешко, Вы писали:
PD>>Прыжками — это goto ? С фортрановских времен не писал. Как-нибудь обойдусь.
П>Вы упомянули break, которым могли бы раньше выйти из цикла, а он и есть тот же самый прыжок. П>ФВП тоже могут остановить цикл прохода по последовательности, тем же break, только это скрыто внутри них, а я не буду думать куда этот break перенесёт поток управления, я просто получу результат.
Я не спорю, что это может быть понятнее, но какой ценой!
PD>>Кто же за бедную машину-то заступится ? Жалко ее. Столько бессмысленной работы делать!
П>Это не бессмысленная работа, просто другой способ исполнять ту же работу, просто менее эффективный в силу архитектуры.
А кому нужен автомобиль, который ездит в 5 раз медленее в силу архитектуры ?
PD>>И коли в ИТ такой подход не вызывает противодействия — значит, что-то неладно в Датском Королевстве.
П>Задачи становятся всё сложнее и сложнее, сложность кода возрастает и одними циклами просто уже не обойтись.
Ну не надо. Все эти "сложные задачи" (в том. что все становится сложнее и сложнее, не уверен, но не буду сейчас говорить) решаются императивными циклами и т.д. И вообще ИМХО еще не придумали задач, которые императивными языками вообще не решаются. Доказательство простое — исполняться будет в конечном счете ассемблерный код, а там ничего другого нет (подчеркиваю, доказательство, а не призыв писать на ассемблере). Так что обойтись в приницпе можно всегда. Хотя да, это может оказаться не очень простым и не очень понятным. Но в любом случае — если ты это не сделаешь, это сделают за тебя (LinQ или иная исполняющая система). И не лучшим образом, как видно даже из этого простейшего примера, что уж говорить о более сложных!
П>Да, самый низ лучше строить на императивных циклах, но задачи чуть выше гораздо удобнее описывать в терминах ФВП.
И все же — не слишком ли дорогой ценой? Вот топикстартер , если и впрямь использует этот красивый код, понизит быстродействие в 3-6 раз. Иными словами, это примерно то же самое (не придирайся к деталям), как если бы вместо машины на 3 Ггц он использовал машину на 1 ГГц, а то и на 500 Мгц. То есть отбросит нас на 2-5 лет назад. Во имя того, чтобы ему было проще это несчастное суммирование делать ? А потом это войдет в норму (ох, не вошло ли уже?), и все будут уверены, что такой код и должен с таким быстродействием работать. И мы так и не узнаем, что могли бы иметь многие программы. Потому что эти программы никогда не будут написаны. А не будут потому, что оценка их быстродействия, основанная на текущем состоянии, даст, что для них надо 20 ГГц, а где их взять ? А в реальности им надо не 20, а только 3, и вполне можно было бы их сделать...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> И мы так и не узнаем, что могли бы иметь многие программы. Потому что эти программы никогда не будут написаны. А не будут потому, что оценка их быстродействия, основанная на текущем состоянии, даст, что для них надо 20 ГГц, а где их взять ? А в реальности им надо не 20, а только 3, и вполне можно было бы их сделать...
Как где взять? Поставить 8 ядер.
А к тому времени, когда ты напишешь эти программы, используя такие низкоуровневые средства, как циклы, и пофиксишь баги до приемлемого уровня, эти программы уже будут никому не нужны.
Вот куда действительно было бы полезно вложить силы — так это в создание высокооптимизирующих компиляторов. Кстати, код, написанный в декларативном стиле, гораздо лучше поддаётся анализу и оптимизации.
Здравствуйте, Аноним, Вы писали:
П>>let sums = { 0 .. n } |> Seq.scan (+) 0 П>>[/ocaml]
А>расшифруйте пожалуйста эту запись (выделенная часть совсем непонятна)
Это F#. Значит вот что: берем функцию Seq.scan, применяем ее к 2 аргументам: к функции, складывающей 2 числа, и к числу 0. Получается функция, принимающая один аргумент. И ей мы скармливаем (|>) последовательность чисел от 0 до n.
Здравствуйте, nikov, Вы писали:
П>>>let sums = { 0 .. n } |> Seq.scan (+) 0 П>>>[/ocaml]
А>>расшифруйте пожалуйста эту запись (выделенная часть совсем непонятна)
N>Это F#. Значит вот что: берем функцию Seq.scan, применяем ее к 2 аргументам: к функции, складывающей 2 числа, и к числу 0. Получается функция, принимающая один аргумент. И ей мы скармливаем (|>) последовательность чисел от 0 до n.
Можно подробнее почитать в MSDN, например, начиная отсюда.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А если честнее потому, что это более соответствует тому, что генерируется LinQ — то мне до этого и дела нет. Задача поставлена ясно
PD>//////////////////////////////////////////////////// PD>Есит ряд:
PD>1, 2, 3, 4, ..... n
PD>Надо через LINQ получить из него ряд частичных сумм:
PD>1, 3, 6, 10, ... m
PD>////////////////////////////////////////////////////
PD>Вот я и сделал этот ряд частичных сумм, и пусть мне кто-то докажет обратное.
См. выделенное
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, nikov, Вы писали:
PD>> И мы так и не узнаем, что могли бы иметь многие программы. Потому что эти программы никогда не будут написаны. А не будут потому, что оценка их быстродействия, основанная на текущем состоянии, даст, что для них надо 20 ГГц, а где их взять ? А в реальности им надо не 20, а только 3, и вполне можно было бы их сделать...
N>Как где взять? Поставить 8 ядер.
Так ведь если поставить 8 ядер, получится все равно то же самое, только на другом, более высоком уровне. Ты будешь их использовать как 3 GGz, а для того, чтобы использовать все 20, тебе понадобится 120 . Суть-то проста — используется 20% реальной мощности, независимо от того, чему она равна.
N>Вот куда действительно было бы полезно вложить силы — так это в создание высокооптимизирующих компиляторов. Кстати, код, написанный в декларативном стиле, гораздо лучше поддаётся анализу и оптимизации.
Здравствуйте, gandjustas, Вы писали:
PD>>И что ? В том массиве, что я сделал, ее найти нельзя ? Кстати, если уж именно это надо — оборву цикл, как найду первую сумму, которая больше заданного, ибо дальше будет еще больше . И для этой задачи и массив-то совсем не нужен. Ни один. Суммируй в одну переменную пока сумма >= заданного не станет, и отмечай максимальную из четных.
G>именно этим код со scan и занимается G>Только возможностей по композиции у него гораздо больше. G>Тебе же придется переписывать большую часть кода при незначительном изменении условий.
Придется.
G>>>или еще как-то скомбинировать результирующую последовательность с другими операциями. PD>>Кто мешает ? G>Циклы мешают.
Ты считаешь, что их реально нет в коде, сгенерированном LinQ ? Или это просто продолжение предыдущего — что мне придется многое переписывать ? Если второе — да, согласен, но я не согласен с тем, что ради того, чтобы сделать жизнь программиста легче, можно позволить себе 5-6 кратное замедление.
Ну а с тем, что это можно написать с циклами (да, сложнее) я думаю, спорить ты не будешь.
Здравствуйте, Qbit86, Вы писали:
Q>У вас в конторе код набирают машинистки под диктовку?
У Вас принято все слова понимать буквально ? Или надо расшифровать, что я имел в виду ?
PD>>Меня не интересует простота восприятия.
Q>Павел, вы, видимо, не работаете в коллективе?
Работаю. В сильно распределенном коллективе
PD>>Сколько времени в мсек этот код работает? Запусти и приведи результат.
Q>Я по-умолчанию предполагаю, что наиболее простой для восприятия код с эквивалентной асимптотикой работает достаточно быстро — пока не доказано обратное.
А я именно обратное и доказал, правда, не для твоего примера, а для LinQ. А что касается твоего примера — предполагай что хочешь, твое право, но пока ты не дашь доказательства твоего предположения (в секундах и миллисекундах), твое предположение ничего не стоит.
Может, хватит всяких прочих утверждений ? Приведи время работы!
>Когда будет доказано — и не в попугаях, а в профилировщике (т.е. с учётом частоты выполнения участка кода) — только тогда и надо думать об оптимизации.
В общем так. Все голословные утвреждения меня мало интересуют. Равно как и рассуждения о том, что надо и что не надо оптимизировать. Это другой вопрос. Либо приводи время работы своей программы, либо не стоит продолжать.
Q>Павел, современные машины в вашей защите не нуждаются, честно Чай не маленькие. Тем более в защите от ветряных мельниц.
Здравствуйте, Pavel Dvorkin, Вы писали:
Q>>У вас в конторе код набирают машинистки под диктовку?
PD>У Вас принято все слова понимать буквально ? Или надо расшифровать, что я имел в виду ?
Да, лучше расшифруйте. Я уж не знаю, что вы имели в виду проводя заведомо дырявую аналогию между машинисткой и разработчиком. В данном контексте я трактую слово «машинистка» как низкоквалифицированного работника, который играет далеко не ключевую роль, и падение производительности которого почти никак не скажется на работе предприятия. И противопоставляю ему «разработчика» — квалифицированного высокооплачиваемого работника, трата времени которого на погрузку мебели или починку сантехники — это прямые убытки. Если разработчик самовольно и без веских оснований начинает пи****сить байты и такты [меня уже банили за процитированный мат], то это в некоторых местах справедливо называют саботажем.
PD>>>Меня не интересует простота восприятия.
Q>>Павел, вы, видимо, не работаете в коллективе?
PD>Работаю. В сильно распределенном коллективе :-)
:D Павел, ну вы всерьёз, что ли? Ну кто вас учил так доказывать?
1) Предвзятость выборки и категорически некорректный её анализ. а) Вы сравниваете функции по значению в одной точке. Супер. Аналогичным способом можно заключить, что функция x + 10 в десять раз «больше» функции e^x, потому что это справедливо для точки x = 0. b) Значения функций в некоторой точке отличаются в 5 раз (скажем, 1 секунда и 5 секунд), но обе функции линейны — играет роль «константа». Какая — аддитивная или мультипликативная? Если увеличить размер массива в сто раз, то значения функций будут соотноситься в 5 раз или на 4 секунды? Или какое-то промежуточное значение? Ваше «доказательство» как-то обосновывает ваши «в пять раз»?
2) Не учтён контекст. Где и как будет вызываться код, на какие условия эксплуатации рассчитан? Например, если речь идёт о времени респонса на действие пользователя в GUI, то он может просто не заметить разницы во многих случаях. С точки зрения машины, он тупо медленно тягает мышь.
3) Не оценена систематическая ошибка. Вы уверены, что DateTime.Now подходящий инструмент? Или, быть может, лучше frequency counter'ы?
4) Оценка правдоподобия полученного результата. У вас она где? Есть проверка своего исследования? Вот я смотрю, а у вас там
нули суммируются. Это тоже распространённый случай исследовательской недобросовестности — не так тщательно проверять «удобные» результаты — именно этот случай отдельно оговаривал Фейнман в известной лекции, включённой главой «Культ Карго» в автобиографическую книжку.
PD>А что касается твоего примера — предполагай что хочешь, твое право, но пока ты не дашь доказательства твоего предположения (в секундах и миллисекундах), твое предположение ничего не стоит.
Презумпция невиновности «нулевой гипотезы» или «принцип отсутствия достаточных оснований». Нет достаточных оснований, чтобы считать LINQ виноватым.
Или — пока вы не сфотографируете свой мозг и не дадите пруфпик в студию, ваше предположение о его существовании «ничего не стоит». Примерно такого же уровня рассуждения, и вестись на них я не буду. Доказывать, что я не верблюд — тоже.
PD>Может, хватит всяких прочих утверждений ? Приведи время работы!
Не вижу на то оснований, чтобы что-то доказывать. Такова логика науки, читайте того же Имре Лакатоса или Карла Поппера. Существует бесконечное множество утверждений, причём неверных или бредовых неизмеримо больше. На всех времени не напасёшься, чтобы их опровергать. Чтобы заняться опровержением какой-то гипотезы, нужны основания. Пока что практика использования LINQ не даёт оснований всерьёз опасаться падения производительности в абсолютном большинстве задач. Ваша гипотеза о том, что LINQ-де безбожно тормозит, а циклы рвут его в клочья и вообще must use, пока что интересна не более, чем чайник Рассела.
>>Когда будет доказано — и не в попугаях, а в профилировщике (т.е. с учётом частоты выполнения участка кода) — только тогда и надо думать об оптимизации.
PD>В общем так. Все голословные утвреждения меня мало интересуют.
Утверждение о существовании у вас мозга не менее голословно. А ну-ка докажите! (Это просто пример, я не хочу обидеть, честно! Просто хочу объяснить, что в некоторых случаях вы не вправе требовать доказательств.)
PD>Равно как и рассуждения о том, что надо и что не надо оптимизировать. Это другой вопрос. Либо приводи время работы своей программы, либо не стоит продолжать.
В этой реплике содержится ложная пресуппозиция о том, что я должен — согласно логике дискуссии — приводить время какой-то программы. А это не так. Я говорю не в том смысле, что мне не интересно её приводить. И не в том ключе, мол, я не буду тратить на вас время. Я подчёркиваю — я и не должен обосновывать любое на ваш выбор утверждение. В дискуссии у оппонентов принципиально асимметричные роли, это важно понимать. В данном случае вы пытаетесь «сдвинуть парадигму» — убедить в малопригодности LINQ'а, а не наоборот — я вам пытаюсь его навязать.
. И для этой задачи и массив-то совсем не нужен. Ни один. Суммируй в одну переменную пока сумма >= заданного не станет, и отмечай максимальную из четных. 
