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

Там учли особенности работы подсистемы памяти. Формальная оценка сложности там тоже есть, но она к реальным задачам никакого отношения не имеет а относится лишь к модели «сферического вычислителя в вакууме».

Приведу такой результат этого учета - для у-й максвелла и у-й сплошной среды (сейсмика) реально достигнутая за счет LRnLA производительность порядка десятков тактов на ячейку на шаг при размере сетки 1024х1024х1204 на вполне обычной персоналке. Говорит о чем нить?

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

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

Мат.*, пыхтон, С++. Што значит - научные? :]

Я такую экономию байтиков и тактов считаю скорее «грязными машинными штучками», чем собственно самим алгоритмом. Хотя если изначально стоит задача сделать нечто эффективное, то уже на этапе разработки алгоритма стоит задумываться о таких тонкостях его реализации (на Си?). В общем-то всё правильно они сделали :)

> большинство сегодня по инерции еще пишут на Фортране или Си, но ведь задачи на сегодняшний день изменились

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

По сабжу: прототипирование и юнит-тесты Wolfram Mathematica®, код в железке - С++ по паттерну «С с классами», и малость компайл-тайма на шаблонах.

Matlab, возможно, удобенее для signal processing, ну и для людей с фортранным мышлением. Мне ближе математика, кода в ней выходит меньше, легко играться с точностью, ну и офигенское качество генерируемой графики + минимум постобработки (важно для статей).

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

ЯП - С++ (суровые шаблоны) и питон. На питоне хитрый кодогенератор + интерфейс и вся обвязка.

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

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

Ну то, что их учат на первых-вторых курсах на бейсике я за знания не считаю.

Што значит - научные?

Научные - связанные с наукой - численные расчеты по химии, физике и т.п.

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

Математика конечно удобна, но не всегда. Да и с инкапсуляцией и разработкой модулей там гемор. Качество генерируемой графики - средне (мне gnuplot или tecplot нравится больше).

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

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

> 90% готовых научных либ вообще-то на фортране

На Фортране 77 :-) Это такое старьё, что никто и поддерживать не берётся. Хотя альтернатив, по большому счёту, нет.

На matlab

> офигенское качество генерируемой графики + минимум постобработки (важно для статей).

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

Научные - связанные с наукой - численные расчеты по химии, физике и т.п.

знаю одного физика-ядерщика, который пишет на Scheme. статьи с соответствующим кодом публикует

другой знакомый физик (тоже, впрочем, ядерщик) активно использует J

> На питоне хитрый кодогенератор

Преимущества Питона видятся мне только в кодогенерации. Можно об этом по-подробнее? Насколько вообще такие хаки с кодогенерацией играют большую роль?

>Научные программы

Что это?

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

from mymodel import *
M = myclass()
M.a = 1
M.b = 2
...
while M.time<time_max : M.calc()
...

Форточки тоже легко цепляются. С таким подходом новая задача с нуля пишется за часы.

А кодонерация - ну чего там... нужно склепать делать сотню С-функций (гран условия). Они очень похожи, где то индексы переставлены где то знаки поменяны. Ищем закономерности, пишем кодогенератор. Тут как раз какой нить лисп наверное лучше подошел бы, да у нас его никто не знает;-)

Мы пилим потихоньку CAS на питоне заточенную на кодогенерацию, да уж больно непростое это дело. Ну че та уже работает, как допилим будет всеобщее щастье человеческое - схему численную вбил, получил на выходе самый эффективный в мире код на С++;-)

Спасибо за ответ. Коль уж за «всеобщее щастье человеческое» ратуете, то желаю удачи в столь благом начинании!

На Фортране 77 :-) Это такое старьё, что никто и поддерживать не берётся.

Вы будете смеяться, но некторые Ъ-научные олдфагодяди на нём и новые проекты пишут, и ведь не переучишь и слова поперёк не вставишь :)

> Вы будете смеяться, но некторые Ъ-научные олдфагодяди на нём и новые проекты пишут, и ведь не переучишь и слова поперёк не вставишь :)

А молодежь даже за хорошие деньги на такое не идет. Куда популярнее сейчас Си или Си++ как «Си с классами». Вот GSL по утверждениям вообще с нуля пишется.

> Вы будете смеяться, но некторые Ъ-научные олдфагодяди на нём и новые проекты пишут, и ведь не переучишь и слова поперёк не вставишь :)

А молодежь даже за хорошие деньги на такое не идет.

молодёжь нынче наглая пошла, приходят ничего не знают, ничего не умеют, опыта - 0, но хотят от 60 т.р.

а нормальная молодёжь всегда пляшет от задачи, если задача интересная, то можно и на фортране опыт получить (а потом втихаря на С++ перепилить)

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

Лень читать весь тред — кто-нибудь уже сказал, что Фортран тоже изменился? man Fortran 2008, к примеру.

Вы будете смеяться, но на нем порой действительно удобно писать ;-)

Я привык проектировать на всяких APL/J, когда довожу идею до конца, переписываю на Фортране.

// сфера — теория приближений и теория оптимального управления

> а нормальная молодёжь всегда пляшет от задачи, если задача интересная, то можно и на фортране опыт получить (а потом втихаря на С++ перепилить)

Если программа полностью написана самостоятельно. А то часто используются специфические библиотеки, такие как NAG library, IMSL. Отказаться от подобного удобства тяжело, уже просто переписать всё на C/C++ не получится. Да и лень что-то менять, если и так всё работает.

> Лень читать весь тред — кто-нибудь уже сказал, что Фортран тоже изменился? man Fortran 2008, к примеру.

Уже сколько лет существует Fortran 90, а приличных библиотек на нём не появилось. На том же www.netlib.org или Fortran 77, или Си (полученная, как правило, посредством f2c). Выводы напрашиваются сами.

Я не говорю, что новый Фортран хорош, просто он есть и развивается. А так, мне хватает F77.

> А так, мне хватает F77.

Ох, подставить сюда любой понравившийся язык. Чем вообще F77 может быть лучше Си?

Я в каком-то недавнем треде уже писал, что на самом деле разницы между серьезными языками нет, не Brainfuck какой-нибудь же. Дело привычки.

Мы в своё время пытались писать числодробление на питоне и numpy/scipy, основной профит видели в том, что можно быстро прототипировать и быстро менять текущий код. Но быстро осознали, что одним питоном не обойтись, т. к. любые операции с числами на голом питоне тормозят ЛЮТО. Поэтому стали отдельные куски переводить на pyrex/cython и на C++. В идеале хотели сделать что-то по принципу PyQt, когда ты из питона создаёшь необходимые объекты-кубики, подсоединяешь их друг к другу, потом запускаешь основной цикл, и в нём питон уже не используется. А на практике оказалось, что наши алгоритмы рассчётов плохо вписываются в ООП, и универсальные кубики сделать нифига не получается: они везде похожие, но не совсем, и если пытаться придумать для них универсальные интерфейсы, то будет настолько сложно и громоздко, что не нужно. В итоге забили и стали писать обычное числодробление на плюсах + немного обвязки на питоне.

ага, по соотношению количество страниц/размер можно детектить родину автора ;)

> Что это?

Тебе не надо, успокойся.

Вы будете смеяться, но на нем порой действительно удобно писать ;-)

да уж всяко удобнее, чем на крестах :) и квалификация попроще нужна

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

> Чем вообще F77 может быть лучше Си?

Массивами, конечно. 6-мерные массивы на C это экстремальный хардкор.

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

Теорема unanimous'а: на любом языке можно написать программу на Фортране.

> то часто используются специфические библиотеки, такие как NAG library, IMSL. Отказаться от подобного удобства тяжело...

... и вовсе не нужно, достаточно описать прототипы в своей программе и дергай библиотеку на здоровье. Конечно, если там не «Фортран с классами» или еще какая хрень.

> Теорема unanimous'а: на любом языке можно написать программу на Фортране.

http://www.pbm.com/~lindahl/real.programmers.html

>> Чем вообще F77 может быть лучше Си?

Массивами, конечно. 6-мерные массивы на C это экстремальный хардкор.

Так и запишем, что Фортран 77 вам неизвестен и знакомство с языками для расчётов - шапочное.

> Теорема unanimous'а: на любом языке можно написать программу на Фортране.

Haskell же.

Фотран уже не тот, я с него ушел из-за усложнения с появлением нового кода.

> Так и запишем, что Фортран 77 вам неизвестен и знакомство с языками для расчётов - шапочное.

Бабушке своей диагнозы ставь, студент.

>> > то часто используются специфические библиотеки, такие как NAG library, IMSL. Отказаться от подобного удобства тяжело...

... и вовсе не нужно, достаточно описать прототипы в своей программе и дергай библиотеку на здоровье. Конечно, если там не «Фортран с классами» или еще какая хрень.

Щито??? Вариант IMSL под Linux в студию.

> IMSL

Я не знаю, что такое IMSL, но судя по твоей реакции — что-то виндовое. Я под винду ничего и никогда не писал. Но библиотеки типа LAPACK превосходно дергаются их C/C++, просто руки надо иметь прямые, а извилины — кривые. И ни в коем случае не наоборот.

Где у Фортран 77 матрицы ты нашёл? Их там никогда не было. Типы данных все приводятся к сишным (заодно узнай, что такое f2c, и почему она перегоняет только F77).

Вариант IMSL под Linux в студию.

CLAPACK, не?

> Где у Фортран 77 матрицы ты нашёл? Их там никогда не было.

Ты идиот? Я про матрицы ничего не говорил, только про массивы, кои в 77 фортране (g77) поддерживаются до размерности вплоть до 7.

> про массивы

К сожалению, только статически аллоцируемые, ну или одномерные — на стеке, но стеки в линуксе по-умолчанию маленькие.

> Но библиотеки типа LAPACK превосходно дергаются их C/C++

Опять лопухнулся. Есть же clapack и lapack++. И да, LAPACK написан на Фортран 77, а вот какую-нибудь библиотеку на Фортран 90/95 к C/C++ не прикрутишь. Посмотри на cfortran и какие у них там походу трудности.

>> Вариант IMSL под Linux в студию.

CLAPACK, не?

IMSL может решать ОДЕ, вместо нее на Linux использую GSL.

> Опять лопухнулся. Есть же clapack и lapack++.

Я знаю про них, но это сторонние проекты, накой мне пихать в систему то, чего нет в репе? При том, что LAPACK прекрасно используется без этих костылей для impaired persons.