Язык программирования для математика

[cupuyc_]

nestoklon в сообщении #419623 писал(а):

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

Да, да, решили. Ответьте честно на вопрос: оптимально? Чем Ваш вариант лучше остальных? Тем, что в нём куча классов, которые только усложняют архитектуру программы? Самое интересное - эти классы Вам ничего не дали. Вам всё-равно пришлось использовать лямбду :)))

nestoklon в сообщении #419623 писал(а):

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

Глупость какая-то. Вы понимаете под словом "функция" что-то своё. В эрланге функции точно также описываются, тоже принимают аргументы и тоже содержат описание этих аргументов.

nestoklon в сообщении #419623 писал(а):

Да, я уже спрашивал, зачем Вы наплодили функций, повторяю вопрос. Вы не оценили иронии. Намекну, в ФП оперируют функциями, с ООП -- объектами.

Ваши классы не делают ничего. Просто классы ради классов. Лишний код, который только затрудняет понимание программы. Не даёт ни масштабируемости, ни универсальности, ни производительности. У меня каждая функция выполняет элементарную операцию. Скажем, функции sum, psum, for потом можно будет использовать в других функциях. Как следствие - универсальность кода. В моём коде как раз-таки нет лишних сущностей, которые бы заструдняли понимание кода. У Вас же их море. Вся программа - сплошной антипаттерн.

nestoklon в сообщении #419623 писал(а):

Проинтегрируйте пожалуйста функцию от двух переменных.

По одной из переменных (н-р $F(x) = \int_{0}^{1}f(x, y) dy$)? Или двойной интеграл по обеим? Сформулируйте полностью задачу. Я не понимаю в чём здесь сложность.

[nestoklon]

cupuyc_ в сообщении #419630 писал(а):

Ответьте честно на вопрос: оптимально?

Ну, довольно близко к.

cupuyc_ в сообщении #419630 писал(а):

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

В таком случае, повторяю вопрос с которого мы начали. "И чем же он в таком случае лучше с++?" Тем, что Страуструп так сказал? Или он не так сказал?

cupuyc_ в сообщении #419630 писал(а):

Ваши классы не делают ничего

А что они должны делать? Это ж классы.

cupuyc_ в сообщении #419630 писал(а):

Вся программа - сплошной антипаттерн.

Ути-пути, какие мы слова знаем.

cupuyc_ в сообщении #419630 писал(а):

Сформулируйте полностью задачу.

cupuyc в сообщении #418202 писал(а):

Многомерный интеграл: $\int_{0}^{1}{\int_{sin{x}}^{cos{x}}{x y^2 (2 x + 3 y)}} dx}$

Maslov в сообщении #418741 писал(а):

В качестве теста считается интеграл
$\int\limits_{-1}^{1}dx\int\limits_{-\sqrt{1-x^2}}^{\sqrt{1-x^2}}\frac 3 2 \sqrt{1 - x^2 - y^2}~dy$

Для начала.

cupuyc_ в сообщении #419630 писал(а):

Я не понимаю в чём здесь сложность.

Я, право слово, тоже не понимаю. И с самого начала не понимал. Это Вы утверждали, что есть какие-то нетруднопреодолимые сложности.

[cupuyc]

nestoklon в сообщении #419682 писал(а):

Ну, довольно близко к.

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

nestoklon в сообщении #419682 писал(а):

В таком случае, повторяю вопрос с которого мы начали. "И чем же он в таком случае лучше с++?" Тем, что Страуструп так сказал? Или он не так сказал?

Начали не мы, а именно Вы. Я говорил о другом и повторил несколько раз. В данной задаче лучше тем, что ООП и метапрограммирование здесь не дают должного результата, они всё чрезмерно усложняют. А вот некоторые концепции ФП позволяют писать простой и понятный код (опять же в данной задаче).

nestoklon в сообщении #419682 писал(а):

А что они должны делать? Это ж классы.

Так что так мало создали? Создали бы ещё сотню штук - был бы хардкорный плюсный код.

nestoklon в сообщении #419682 писал(а):

Это Вы утверждали, что есть какие-то нетруднопреодолимые сложности.

Да, Вы эти сложности продемонстрировали.

Так посчитали ведь уже интегралы, сообщении #418202. Чего Вы ещё хотите?

[nestoklon]

cupuyc в сообщении #419691 писал(а):

А вот некоторые концепции ФП позволяют писать простой и понятный код (опять же в данной задаче).

Ну да, всё так. Только это говорили не Вы, а я.

cupuyc в сообщении #419691 писал(а):

Чего Вы ещё хотите?

Уже ничего. В принципе, я продолжал этот разговор по одной причине -- мне в самом деле ненадолго стало любопытно, знаете ли вы с++ хоть немного. Я это выяснил.

[cupuyc]

nestoklon в сообщении #419697 писал(а):

Ну да, всё так. Только это говорили не Вы, а я.

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

nestoklon в сообщении #419697 писал(а):

Уже ничего. В принципе, я продолжал этот разговор по одной причине -- мне в самом деле ненадолго стало любопытно, знаете ли вы с++ хоть немного. Я это выяснил.

Как Вы что-то можете выяснять, если сами его не знаете?

[Toucan]

cupuyc,nestoklon
если дискуссия в подобном стиле будет продолжаться, закрою тему.

[Postrelyonysh]

caxap в сообщении #325937 писал(а):

Ищу ЯП, чтобы можно было легко писать разные математически-направленные проги. Ну посчитать что-нибудь (по ТВ, например) или переборную задачу и т. п. Главное удобство, пусть даже в ущерб скорости.

Вам нужен язык, обеспечивающий хороший уровень абстракции - такие языки традиционно относят к "декларативной" парадигме. Это нужно для обеспечения высокого показателя Code Reuse - чтобы и вам самому не пришлось по десять раз переписывать одну и ту же мат.функцию для разных применений, и люди, занимающиеся прикладными науками, не взаимодействующие с математикой напрямую, могли воспользоваться вашими наработками.

Из более-менее распространённых - диалекты и потомки Lisp (Scheme, Common Lisp), ML (SML, OCaml, Haskell); логические (Prolog). Из коньюнктурных соображений можно взять и мультипарадигменные/гибридные (вроде Python), но они могут быть для вас менее удобны, т.к. изобилуют сугубо программерскими (не математическими) фишками. Специально для ваших целей разрабатывается Fortress (ФПшная замена Фортрана). Рекомендую также первоначально поиграться с языками Рефал и Joy - это очень простые языки, но с весьма экзотичной семантикой - их усвоение поможет лучше понять многие аспекты других языков, более характерные сугубо для программирования (не математики), выбить из головы последствия императивного программирования и научиться более элегантно использовать тот же Haskell, избегая вот таких казусов. Erlang - узко специализированный инструмент, так что не факт, что он будет для вас наилучшим выбором (хотя его достоинства здесь озвучены), он всё-таки больше для телекоммуникаций и прочих тяжело нагруженных серверов.

>Maslov:
Вам нужно учиться отличать причину от следствия и извлекать из любого факта его первопричину - в этом умении и заключается разница между "устройством" головы и её "наполнением". (Даже информация непосредственно от первоисточника может быть не первопричиной, а следствием - если первопричина была для автора слишком интуитивно-самоочевидной, чтобы её озвучивать; если написанием руководства занимался ассистент с неправильным пониманием идейной сути, заложенной автором; если были применены общепринятые buzzwords ради популяризации продукта среди хомячков; ради умышленного сокрытия первопричин из соображений высокомерия, и пр.)

Например, к вашему сведению, отказ от присваиваний в ФП - это следствие, а не первопричина (и потому зачисление Лиспа в функциональную парадигму, вообще говоря, ошибкой не является). То же касается и основанности Лиспа на лямбда-исчислении. То же, естественно, касается и роли list comprehensions в Хаскеле. Более того, я таки вчитался в ваше описание внутреннего представления 'foreach' на C# и обнаружил, что оно полностью аналогично оному для Python. Просто вы смысл текстом изложили перректально, перевернув с ног на голову все причинно-следственные связи, по-алголовски - поэтому я сразу и не понял. Я же говорил в другой теме, что алгольщик так везде по-алголовски писать и будет. Хорошее программирование от плохого отличается направлением мышления. Хороший программист думает: "нам требуется получить такие-то и такие-то вещи, давайте теперь подумаем, что нам потребуется сделать, чтобы их реализовать?", а плохой - "в нашем распоряжении есть такие-то и такие-то вещи, давайте теперь подумаем, что мы можем с их помощью реализовать!". (Собственно, второе направление и привело к выращиванию уродливой раковой опухоли под названием "С++ и БООСТ (Большая Опухоль От Страусовых Темплейтов)"). Вам может показаться, что на практике эти направления будут пересекаться и чередоваться, но это алголовское заблуждение. Хорошее программирование всегда идёт от что к как; а если вы будете играться с каками, надеясь сложить из них что-нибудь, то облом - только каку и получите.

Так вот, необходимость прописывать методы 'iter/next' ('GetEnumerator/MoveNext' у вас) - это вынужденность, проявившаяся из необходимости существования в языке 'foreach', а никак не наоборот. Это не "сахар над языком", это сам язык. С таким же успехом можно было бы назвать конструкторы и деструкторы в С++ - "сахаром над классами". Просто тем программистам, которые понимают важность глаголов для выражения своих мыслей, требовался высокоуровневый глагол 'foreach', но в Королевстве существительных, в котором вы живёте, для его реализации пришлось издать королевский указ об обязательном содержании высокопоставленными существительными у себя в подчинении мелких глагольчиков 'iter/next'. Причина и следствие. Вы, конечно, можете вызывать 'iter/next' напрямую, императивно, но этим вы нарушите абстракцию, получите VB/Delphi-программу на Python и поставите архитектуру под угрозу фатального краха при изменении ТЗ.

Maslov в сообщении #419334 писал(а):

вопрос-то был в другом: знаете ли Вы, в каких языках 'region inference' применяется для управления памятью?

Если вы ещё не заметили, вопросы здесь задаю я.

[Munin]

Postrelyonysh в сообщении #419827 писал(а):

Если вы ещё не заметили, вопросы здесь задаю я.

Это недолго :-)

[Postrelyonysh]

nestoklon в сообщении #419613 писал(а):

К сожалению для ФП и к счастью для всего остального, функция нескольких переменных на С++ -- это настоящая функция нескольких переменных, а не функция от одного словаря.
Хотя, что я объясняю...

Ну да, правда, что вы объясняете, если не знаете, что такое функция нескольких переменных.
Wiki: Функции нескольких аргументов
На Рефал взгляните - может, поможет.

[nestoklon]

cupuyc в сообщении #419701 писал(а):

что на плюсах можно написать лучший код?

Подтвердите цитатой пожалуйста. Потому что этого я не говорил.

cupuyc в сообщении #419701 писал(а):

К чему был весь это спор?

Итак, возвращаемся к началу. Мой вопрос был "Чем эрланг лучше". В ходе дискуссии выяснилось, что он "лучше" потому что он ФЯП. А ФП Вам больше нравится потому что ООП Вы не знаете.
Моё утверждение состояло в том, преимущества ФП для нужд физических расчётов сомнительны. Этот момент Вы отказались обсуждать принципиально. Однако, для физических расчётов матмодель как правило не должна обладать особой гибкостью. Даже, слишком большая гибкость будет лишней. Поэтому ФП тут не идеально.
Для математики -- да, без сомнения.

[cupuyc]

Postrelyonysh в сообщении #419827 писал(а):

(Собственно, второе направление и привело к выращиванию уродливой раковой опухоли под названием "С++ и БООСТ (Большая Опухоль От Страусовых Темплейтов)"). Вам может показаться, что на практике эти направления будут пересекаться и чередоваться, но это алголовское заблуждение. Хорошее программирование всегда идёт от что к как; а если вы будете играться с каками, надеясь сложить из них что-нибудь, то облом - только каку и получите.

+

nestoklon в сообщении #419848 писал(а):

Подтвердите цитатой пожалуйста. Потому что этого я не говорил.

Вы говорили по крайней мере то, что никаких проблем с вычислением интеграла не возникнет. И что у эрланга нет никаких преимуществ при решении данной задачи. А потом говорите совершенно обратное:

Цитата:

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

Да в Вашем примере они вообще никак не решаются. Вы использовали лямбду, не поддерживаемую современным стандартом. Мало того, если использовать лямбду, то проблем то вообще никаких нет и нет смысла писать гору ничего не делающего мусора. А Вы ещё заявляете, что ваш код написан оптимальным образом Ещё и делаете какие-то заключения, что Вы знаете ООП, а другие не знают, поэтому не способны понять гору бесполезного кода. А потом ещё и сами заявляете, что код без ООП Вам нравится больше

Цитата:

Лично мне больше всего понравился код Maslov. Код venco короче моего, но там меньше общности, к которой я стремился (возможно зря). Зато без хаков c++0x.

. Где логика?

[nestoklon]

cupuyc в сообщении #419965 писал(а):

Мало того, если использовать лямбду, то проблем то вообще никаких нет

Это утверждение неверное, на что Вам было указано неоднократно. Карринг функции от неизвестного числа переменных даже с лямбдой в с++ не сделать. Приходится что-то делать с функцией. Да, средствами языка. Современного стандарта.

cupuyc в сообщении #419965 писал(а):

Вы говорили по крайней мере то, что... . И что у эрланга нет никаких преимуществ при решении данной задачи.

То есть уже не говорил. Отлично. Вспоминаем дальше. Я выразил сомниние в том, что эти преимущества принципиальны. На что получил массу троллинга и поливания грязью вместо простого ответа.

[cupuyc]

nestoklon в сообщении #420031 писал(а):

Я выразил сомниние в том, что эти преимущества принципиальны.

Ага, опять началось - выразил сомнение. Не зная броду - не лезь в воду. Коли сомневались - нечего было лезть в спор.

nestoklon в сообщении #420031 писал(а):

Это утверждение неверное, на что Вам было указано неоднократно. Карринг функции от неизвестного числа переменных даже с лямбдой в с++ не сделать. Приходится что-то делать с функцией. Да, средствами языка. Современного стандарта.

Да при чём здесь карринг? Был конкретный пример, что Вы меняете тему? Зачем мне функции с переменным числом аргументов для решения задачи численного интегрирования? Приведите конкретный пример, хватит уже пустых утверждений. Вы выдумали какую-то проблему, ни разу её толком не озвучили и утверждаете, что я её не могу решить. Поставьте чётко задачу, я ваших мыслей читать не умею.

[nestoklon]

cupuyc в сообщении #420089 писал(а):

Ага, опять началось - выразил сомнение.

Что значит опять? Оно и не кончалось.

cupuyc в сообщении #420089 писал(а):

Коли сомневались - нечего было лезть в спор.

Простите, я не был в курсе, что это был спор. Теперь буду знать, что отвечая на Ваши комментарии участвую в споре.

cupuyc в сообщении #420089 писал(а):

Зачем мне функции с переменным числом аргументов для решения задачи численного интегрирования?

cupuyc в сообщении #417617 писал(а):

На С++ выйдет тоже самое. Будет не указатель на функцию а указатель на интерфейс. Проблемы это не решит. Кроме того, для каждой функции теперь придётся создавать свой класс, наследуемый от этого интерфейса. Проблема с вычислением многомерного интеграла никуда не исчезнет. Буст здесь мало чем поможет. Если только с потоками попроще будет работать. Ключевое отличие эрланга здесь - возможность написания вложенных функций.

cupuyc в сообщении #417617 писал(а):

Чтобы не продолжать спор, приведите пример кода, чтобы на мах можно было считать многомерныйе интегралы.

Ваши комментарии -- отличный пример марковского процесса. Даже если напомнить Вам о том, что Вы писали незадолго до того, это ни к чему не приводит. Когда Вас спрашивают, на хреназачем для задачи численного интегрирования брать Эрланг, Вы начинаете грузить про то, что "а если вдруг я захочу многомерные интегралы". Потом когда вас спрашивают ну и где Ваши многомерные интегралы, вдруг оказывается что Вы их больше не хотите. Логика пятилетнего ребёнка.

[Toucan]

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

Postrelyonysh в сообщении #419827 писал(а):

Если вы ещё не заметили, вопросы здесь задаю я.

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