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

[Maslov]

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

Всё-таки для математических расчетов, для моделирования физических процессов лучше использовать какой-нибудь функциональный язык.

cupuyc,
а в чём, на Ваш взгляд, преимущество функциональных языков для решения таких задач?

[Munin]

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

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

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

-- 25.02.2011 00:49:34 --

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

а в чём, на Ваш взгляд, преимущество функциональных языков для решения таких задач?

Наверняка, в синтаксическом сахаре :-)

[Maslov]

Munin в сообщении #417016 писал(а):

В функциональных языках проще работать с памятью, не надо возиться,

Сборка мусора не является специфическим атрибутом функциональных языков. В Java и .Net она давным-давно работает.

Munin в сообщении #417016 писал(а):

Наверняка, в синтаксическом сахаре :-)

Ну сахара-то и в императивных (процедурных/ООП) языках предостаточно.

[Munin]

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

Сборка мусора не является специфическим атрибутом функциональных языков.

Я знаю, я говорил в контексте сравнения с плюсами. И потом, сборка мусора в объектных и функциональных языках всё-таки вещи разные.

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

Ну сахара-то и в императивных (процедурных/ООП) языках предостаточно.

Для математики - не слишком. Для неё вообще выразительных средств мало где достаточно. APL, разве что, и специализированные матпакеты.

[Joker_vD]

Munin в сообщении #417036 писал(а):

Для неё вообще выразительных средств мало где достаточно.

Даже на клавиатуре, зараза, нету большинства нужных кнопок.

[Maslov]

Munin в сообщении #417036 писал(а):

И потом, сборка мусора в объектных и функциональных языках всё-таки вещи разные.

А в чём разница?
Под .Net, например, сборщик мусора один и тот же для императивных языков (C#/VB), функциональных (F#) и динамических (Ruby/Python).

[cupuyc]

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

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

[nestoklon]

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

А на эрланге такую прогу можно написать буквально за час.

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

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

а стандартного механизма для этого нет.

А MPI на что?

Со второй частью целиком и полностью согласен.

[Maslov]

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

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

Ну да. Насколько я знаю, основной механизм распараллеливания в функциональных языках -- это "parallel map" -- независимое применение функции к элементам списка. Но подобные возможности есть и большинстве параллельных расширений/библиотек для императивных языков. В эрланге встроенных возможностей, конечно, больше, но он изначально проектировался как язык для программирования распределенной обработки данных.

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

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

В "системном" программировании это тоже нужно: механизм callback'ов используется с незапамятных времен. Но с тех же незапамятных времен нет никаких проблем с его реализацией.

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

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

Какое "колдовство" Вы видите в таком описании?

double Integrate(double (*fnc)(double x), double xMin, double xMax)

Или в C#:

double Integrate(Func<double, double> fnc, double xMin, double xMax) 

И вызов:

double v = Integrate(x => x * x, 0.0, 1.0);

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

А если функция имеет другой синтаксис - вообще беда.

Что имеется в виду?

[Munin]

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

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

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

[Joker_vD]

Munin в сообщении #417149 писал(а):

Например, хочу я проинтегрировать функцию Дирихле...

Да ради бога, хватайте любую формулу Ньютона-Котеса и интегрируйте. За то, что результат имеет хоть какое-то отношение к действительности никто, сами понимаете, не ручается, ну и что?

[Munin]

Вы, это, хотя бы предложите хоть какую-нибудь реализацию функции Дирихле как функции языка программирования. Любого на ваш выбор.

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

[Joker_vD]

Munin в сообщении #417277 писал(а):

Вы, это, хотя бы предложите хоть какую-нибудь реализацию функции Дирихле как функции языка программирования. Любого на ваш выбор.

Легко. Язык Си:

double funcDirichlet(double x) {
  return 1.0;
}

Пожалуй, надо пояснить: тип double представляет только рациональные числа, а иррациональных представить не может в принципе... Кстати, а разве вообще есть численные методы для вычисления интеграла Лебега? Или функция Дирихле уже стала интегрируема по Риману?

[Munin]

Joker_vD в сообщении #417282 писал(а):

Легко. Язык Си:Код:double funcDirichlet(double x) {  return 1.0;}

Вот именно :-) А нужна функция Дирихле, а не константная единица. Кстати, интеграл от них разный :-)

Joker_vD в сообщении #417282 писал(а):

Кстати, а разве вообще есть численные методы для вычисления интеграла Лебега?

А я разве сказал, что мне надо численно? Речь, вроде, шла о математике.

Ещё задачка того же сорта: дана функция (действительной переменной), надо определить, является ли она аналитической.

[mihailm]

Munin в сообщении #417344 писал(а):

...
Ещё задачка того же сорта: дана функция (действительной переменной), надо определить, является ли она аналитической.

И как она задана?