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

[nestoklon]

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

Задайте нормально вопрос - получите ответ.

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

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

Это уже демагогия.

Несомненно, но не я первый начал.

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

При чём здесь параллельные вычисления? Зачем Вы всё мешаете в кучу?

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

[cupuyc]

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

В чём преимущество Эрланга и на каких задачах оно в принципе реализуемо? Про интегрирование я уже понял. Неактуально. Ещё что-то?

Ещё раз повторю по пунктам.
1. Вы написали функцию для расчёта интеграла на С++. Эта функция принимает 3 аргумента и имеет следующий синтаксис:

typedef double integrated(double) ;
double integral(double low_limit, double hight_limit, integrated* func) { ... }

Проблемы:
1.1 Вам нужно вычислить интеграл от функции:

float my_func(float) { ... }

Просто так скастить указатель нельзя. Придётся функцию my_func оборачивать в другую, чтобы она соотвествовала синтаксису integrated. Не то, чтобы проблема, но как-то коряво получается. Мало того, функция может зависеть от параметров и нужно, например, вычислить интеграл несколько раз с различными значениями этого параметра.
1.2 Вам потребовалось вычислить двойной интеграл функции двух переменных. Написанную ранее функцию для этой цели использовать уже не получится, т.к. пределы могут быть переменными. Нужно что-то переделывать. На Эрланге такой проблемы не возникает.
1.3 Есть функция векторного аргумента сложная в вычислительном плане. Вам нужно посчитать многомерный интеграл. Если считать в одном потоке, то вычисления могут занять кучу времени.

Все эти проблемы, конечно же решаемы и на С++. Суть не в этом. Суть в том, что В Эрланге этих проблем либо вообще нет (1.1, 1.2), либо они решаются значительно проще (1.3), стандартными средствами языка.

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

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

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

Это уже конструктивно. Понятное дело, что гвозди отвёрткой забивать неудобно, для каждой задачи должен быть свой инструмент.
Язык С++ хорошо зарекомендовал себя с системном программировании. Язык постоянно развивается. Сначала он был просто надстройкой над языком С, сейчас совместимость с С программами, вообще говоря, отсутствует. Отсюда и пошли многие проблемы. Microsoft попыталась решить существующие проблемы в языке C#. Но у неё это плохо получилось. Шарпные приложения непереносимы, а на плюсах можно писать мультиплатформенный код - хоть под линь, хоть под вынь, хоть под x86, хоть под ARM. Кроме того, шарп заточен под дотнет со всеми вытекающими последствиями. Вообще MS при разработке своих продуктов меньше всего думает об их переносимости, универсальности. Часть проблем бвла решена в относительно новом языке D, в котором нет никакой обратной совместимости ни с C, ни с С++. Мало того, переработан механизм шаблонов, запрещено множественное наследование, упрощён процесс написания классов (в С++ нужно писать много лишнего кода), добавили кое-какие фичи из функциональных языков (н-р вложенные функции). Так что если выбирать между C++ и D, оценивать сами языки, не учитывать наличие уже созданных под них библиотек, существование компиляторов под различные архитектуры и пр., то выбор, конечно же будет в пользу языка D.
Почему всё пишется на С++ вполне очевидно. Есть куча компиляторов для всевозможных архитектур, есть куча готовых библиотек. Язык С++ некоторые учат ещё в школе, переучиваться с туманными перспективами (будет развиваться он или нет - черт его знает) мало кто хочет. Аналогичная ситуация с Эрлангом.
Теперь, собственно к теме разговора. ТС хотел узнать какой ЯП лучше подходит для математических вычислений. Я считаю, что Эрланг довольно удобен для этих целей по ряду причин, которые я назвал выше. Кроме того, у Эрланг есть замечательная возможность - вызывать функции из сторонних библиотек. Если уж так сильно хочется заюзать ALGLib, то можно написать соответствующую длл-ку.

[nestoklon]

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

Это уже конструктивно.

Ну да, и со всем что написано ниже я уже готов согласиться на 100%.
А вот с тем, что написано выше я не согласен. То, что вы привели -- это не С++, это практически голый С. На С++ эта задача решается точно так же как и на функциональных ЯП. То есть, функция должна наследоваться от (скорее всего абстрактного) класса "функция", интеграл будет принимать этот класс и (возможно) класс параметров и области определения. Уверяю Вас, глубоко внутри ФЯП это всё именно так и реализовано. В самом деле, если Вы не хотите не о чём этом думать, то лучше взять ФЯП. И с этим я согласился с самого начала. Но если вам нужна скорость или что-то менее стандартное, то придётся спускать на более низкий уровень. При этом, и на С++ при наличии некоторой степени умений Вы тоже можете не особо заморачиваться, а использовать готовые решения например из boost.
То есть, первый обман состоит в том, что подход чем-то отличается. Ничем он не отличается. Просто в ФЯП все эти обёртки уже вделаны в стандарт языка, что в самом деле иногда экономит время (разработки, ценой времени выполнения).
А второй обман состоит в том, что если вы напишете функцию которая будет одинаково считать интегралы разной размерности без каких-либо предположений о виде функции, она это будет делать на редкость убого. На что я старательно намекал довольно давно. Неспроста библиотечные функции как правило считают одномерные интегралы. И только.

[Munin]

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

А почему С++ такой уродливый и на нём пишут подавляющее большинство софта?

Ну точно о синтаксическом сахаре речь... У большинства критиков С++ даже Design & Evolution не читан.

[cupuyc]

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

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

-- Сб фев 26, 2011 19:44:57 --

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

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

А почему С++ такой уродливый и на нём пишут подавляющее большинство софта?

Ну точно о синтаксическом сахаре речь... У большинства критиков С++ даже Design & Evolution не читан.

Я бы сказал, что все критики делятся на 2 категории. Первые - те кто не знают С++, пишут на каком-нибудь Delphi и не хотят переучиваться. Вторые знают С++ и имеют большой опыт разработки, ни один раз сталкивались с костылями и совершенно непонятным поведением языка.
Не совсем понятно что Вы подразумеваете под "синтаксическим сахаром". Мне это словосочетание вспоминается из какой-то RSDN-овской статьи. Тут никакой не сахар, не удобности. Тут совершенно другой подход к программированию. Что же касается С++ - то это просто кривой язык и дело тут тоже не в "сахаре".

[nestoklon]

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

Проблемы это не решит.

Я не вижу в этом проблемы, честно говоря.

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

Кроме того, для каждой функции теперь придётся создавать свой класс, наследуемый от этого интерфейса.

Но ведь именно это и делается в ФЯП! И в С++ можно точно так же "спрятать" этот процесс от пользователя. Более того, он уже спрятан в буст. Несколько коряво (в рамках не самого идеального синтаксиса не самого идеального для этой цели языка), но спрятан же.

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

Проблема с вычислением многомерного интеграла никуда не исчезнет.

Что за проблема-то с вычислением интеграла? Вы хотите работающий код на С++ который в параллель считает интеграл, в том числе несколькомерный? Ну давайте пожертвую парой вечеров, напишу. Хорошее развлечение, да и довольно близко к тому что мне надо, так что пойдёт как тренировка. Вот только сейчас работаы много, так что быстро не обещаю.
Только сформулируйте почётче задачу.

Елинственное что

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

сравним код по наглядности и простоте.

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

[cupuyc]

Цитата:

Но ведь именно это и делается в ФЯП! И в С++ можно точно так же "спрятать" этот процесс от пользователя. Более того, он уже спрятан в буст. Несколько коряво (в рамках не самого идеального синтаксиса не самого идеального для этой цели языка), но спрятан же.

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

Цитата:

Что за проблема-то с вычислением интеграла? Вы хотите работающий код на С++ который в параллель считает интеграл, в том числе несколькомерный? Ну давайте пожертвую парой вечеров, напишу. Хорошее развлечение, да и довольно близко к тому что мне надо, так что пойдёт как тренировка. Вот только сейчас работаы много, так что быстро не обещаю.

Хорошо. Я напишу не за пару вечеров, а за час и именно многопоточный.
Давайте сразу договоримся о методе. Пусть это будет метод парабол.

Цитата:

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

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

[nestoklon]

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

Как Вы не понимаете, мне плевать как это там реализовано. Я этого не вижу.

Я уже понял. Просто я пытался объяснить, что на это плевать далеко не всегда.

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

Я напишу не за пару вечеров, а за час

Ну, в принципе одно другому не особо противоречит.

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

и именно многопоточный.

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

-- Сб фев 26, 2011 18:55:33 --

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

Пусть это будет метод парабол.

Ну и ещё уточните, что вы подразумеваете под параболами в n-мерии.

[cupuyc]

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

[nestoklon]

cupuyc, про параболы уточните всё же.

[cupuyc]

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

cupuyc, про параболы уточните всё же.

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

[Maslov]

cupuyc,
а можете для начала показать на эрланге что-нибудь попроще?
Например, однопоточную функцию вычисления интеграла методом трапеций, которую можно также использовать для вычисления кратных интегралов.
Ну и посчитать с ее помощью интеграл от $f(x, y) = x^2 + y^2$ по единичному кругу с центром в начале координат.

[Munin]

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

Не совсем понятно что Вы подразумеваете под "синтаксическим сахаром".

Все критики делятся на 2 категории: одни знают, что такое "синтаксический сахар", а другие нет. :-)

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

Глупо заморачиваться ради ускорения в 4 раза.

И даже это зависит от конкретной задачи :-)

[Joker_vD]

Синтаксический сахар — это (если я правильно помню) особенности синтаксиса языка, которые не прибавляют выразительных способностей, но позволяют некоторые вещи писать менее уродливо.

[Munin]

С точки зрения некоторых юзеров "менее уродливо", просто в силу того, что они за не-уродство принимают соответствие своим привычкам. Например, привыкли писать 2+3, и не любят, когда надо писать + 2 3. Это играет роль, но только на этапе обучения и слабого знакомства с языком. Когда язык изучен, это уже неважно. Зато важны другие факторы, про которые любители синтаксического сахара уже попросту не в курсе.