На чем сейчас модно писать научные программы?

ну «моё» пту называется Max-Planck-Institut für Astrophysik, а твоё как?

Фаллометрия пошла. Не знаю что именно хотел ТС, но получился годный вброс.

> на python, но есть такие кто пишут на ruby.

Были идеи CAS сделать на Ruby, но ведь нет ничегошеньки.

> А что если алгоритм не совсем известен, а лишь приближенно знаешь что надо сделать. Поэтому приходится перебирать разные варианты, делать кучу расчетов, тестировать. Код сильно меняется, возникают потери времени на изменение кода в Си. Логика и четкость алгоритма становится трудно увидеть из-за большого кода и дополнительных действий (с выделением данных, организаций доп. циклов и т.д.)

Прочитать Дейкстру и перестать попадать в такие неловкие ситуации.

> ну «моё» пту называется Max-Planck-Institut für Astrophysik, а твоё как?

типа крутое ПТУ? поздравляю.

А мое - никак.

> Питоном не пользовался, но не нравится по нескольким причинам:

* Там вечно что-то меняют и ломают

Мастерское владение взаимоисключающими параграфами.

Фаллометрия пошла.

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

>> ну «моё» пту называется Max-Planck-Institut für Astrophysik, а твоё как?

Фаллометрия пошла

Ловсанчег сам на это напросился.

Прочитать Дейкстру и перестать попадать в такие неловкие ситуации.

Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации

Ты про это?

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

типа крутое ПТУ?

типа известное, для тех кто в теме

А мое - никак.

а чего тогда выпендриваешься?

Рад за вас. Одну фразу из комментария прочесть осилили. Хорошо еще, что не утверждаете, что графики и вычисления на Питоне делать лучше всего.

То, что требует скорости я пишу на C++: есть самописная библиотека Fortran-like массивов, позволяющих использовать LAPACK, легко доступны всякие GSL/GMP, плюс в том же GMP(MPFT) можно получить человеческий синтаксис работы с длинными числами. Ну и всякие приятные вкусности, вроде шаблонов, интерфейсов и параллелизма в виде OpenMP делают программирование более приятным.

Прототипы пишу на Maple — numerics в нем конечно медленный очень, зато все фишки функционального программирования + обширная библиотека численных и символьных алгоритмов. Что-то исключительно редкое — на Scheme. Питон не осилил, к сожалению, равно как и Octave.

> Одну фразу из комментария прочесть осилили.

Я даже процитировал две фразы %)

Хорошо еще, что не утверждаете

Зато ты утверждаешь многое.

Я про то, что пока нет формального доказательства правильности алгоритма и его временной оценки, нефиг браться за код.

В прикладном программировании про это забыли сто лет как, ибо там ничего сложнее STL-ных контейнеров не используется. Там исторически сложилось сразу строчить монотонную рутинку, ибо на бумаге это всё равно без толку разрисовывать. Отттуда и подход «написал-потестил-поправил-потестил».

В академической среде практика разработки такого не терпит. Тупо неэффективно тестить и перебирать, когда имеешь дело с фундаментальными алгоритмами. Проще убить недельку на матчасть, зато потом чуть ли не по псевдокоду _точно_ правильного алгоритма закодить программу за часик.

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

> Зато ты утверждаешь многое.

Не знаю, что у Питона за проблемы с версиями, но даже emerge в генте, исправно работающий на одной версии, на другой выдает ошибки. В Funtoo вон на Python2.6 всё тестируют, даже на 2.7 не переходят во избежание проблем со сборкой.

>> Расчеты требуют больше удобного написания программы, чем скорость счета (не продакшен же), но скорость тоже важна.

Simulink ну и матлаб вообще. Хотя it depends от степени научности. Я в институте делал диплоные расчеты на C и lua (первый потому, что знал лучше всего, второй - потому, что это встроенный язык в FEMM).

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

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

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

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

Всё это делается простым подбором констант :)

Вы ищите *универсальный* инструмент, но таковых для расчетов нет.

Всё это делается простым подбором констант :)

Не всегда. Да и ведь не знаешь заранее где проблема.

> Какой процент из тех, кто делает расчёты, является математиками?

Машина считает. Не зря придумывали таки.

Какой процент математиков занимается разработкой алгоритмов

Ну я имею хорошее представление о трёх сортах математиков. Которые специализируются на теории алгоритмов, на фундаментальной математике (кафедра диффуров и компании), и те которые обсчитывают физиков. Так что, допустим 1/3.

Все остальные на обдумывание алгоритма много времени не тратят.

Остальные вообще дел с алгоритмами толком не имеют.

>Расчеты требуют больше удобного написания программы, чем скорость счета

Ну это смотря какие расчеты, если оно неделю считается на обычном железе, то как раз критична скорость расчета ;-)

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

Еще раз повторяю. Закодил верно, алгоритм верен, а результат не тот. Вот после этого начинается вынос мозга.

физика, химия. либо фортран, (поддержка/использования старой базы), либо питон (новый проекты). Лет 5-10 назад был бум на с и с++, но сейчас уже нет.

> Ну это смотря какие расчеты, если оно неделю считается на обычном железе, то как раз критична скорость расчета ;-)

Да я лучше десять раз нажму «умножить» на калькуляторе Windows, чем тормозной пейтон открывать и там в степень возводить! (с)

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

больше всего принесут пользы схема, R, J и c (ну ещё на питоне много всего)

> Вот после этого начинается вынос мозга.

«Отладка» называется.

Кстати заметь, если мы доказали правильность алгоритма, тут уже можно кое-кого подозревать.

Отладка не спасает (приходится распечатывать матрицы, делать специальные тесты (опять кодить)). А после этого искать выход из ситуации - убрать появившиеся новые эффекты.

Ну, кто-то плохо кодит :(

б. нет такого слова! нету! вы тут посидите, а я пока скодю в туалет.

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

Например, есть такое понятие в МКЭ как ложный сдвиг. Суть его заключается в том, что при увеличении сетки вместо уточнения решения происходит обратное. Решается это внесением в алгоритм изменений (уменьшение числа точек интегрирования). А есть и неизвестные эффекты, которые могут появится в новой задаче (что часто характерно для науки).

Ладно устал я сегодня - пойду спать - завтра работать.

Не знаю насчет моды, сам пишу на Фортран77/95 и на Matlab. Скрипты для автоматизации — на Tcl, Lua и bash.

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

// пойду и я, время позднее.

плюсую R, для статистических расчетов самое оно.

Что ж это за область физики такая? Такого рода высказывания попахивают заявлениями отца Фантом ОС.

Научные программы писать не модно /.thread

P.S.: CL.

R, фортран не ниже 95 + любой высокоуровневый язык для склеивания/GUI, если средств R не хватает. Я использую питон, так как scipy,numpy+f2py, matplotlib, который легко в GUI встраивается. Больше ничего и не надо. Matlab и ему подобные - игрушки для студентов

Питон хорош, очень хорош. Писать просто и быстро.

Сам писал «научные программы» на с++. часть на питон. но, если учесть количество готовых либ, то сейчас писал бы на java или любом jvm языке. например на scala.

> Не вижу прямой связи между сложностью и эффективностью.

Человеческий мосг и ЦПУ работает по разному;-) Человек пишет алгоритм так, как удобно ему, для машины такой вариант обычно крайне неэффективен. Что бы написать действительно эффективный алгоритм надо учитывать особенности работы машины, отсюда и возрастание сложности.

Ну Вы погуглите аббревиатуру LRnLA, погуглите... ;-)

> Что ж это за область физики такая? Такого рода высказывания попахивают заявлениями отца Фантом ОС.

Погуглите аббревиатуру LRnLA

90% готовых научных либ вообще-то на фортране и в жаве они заюзываются через одно место

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

И что же там учли? Там где вместо формальной оценки сложности нарисовали график потребления ресурсов? Или там где посреди матчасти вставили картинку иерархии распараллеливания?

>новичкам, которые почти не умеют ни один ЯП.

Почти не уметь ни один ЯП в аспирантуре на технической специальности? Гм…

А задача в основном связана с работой матриц, с функциями и их обвязки сложной логикой

Для таких, вроде как, и придумали Матлаб :)

C++0x/Qt.

И да, дай определение «научная программа».