LAPACK 3.3.0

так в mkl есть же sparse BLAS и PARDISO sparse solver

в mkl если хорошо покопаться то можно найти все по алгебре в разных вариантах. Но спец функций нет, и диффуравнений нет, и интегальных уравнений нет, и тд. Поэтому, например, такие фортранщики как я, дергают и gsl (в обертке с fgsl), и nag, и hsl, и imsl, и много других полезных и не очень библиотек. Выглядит все это потом ужасно конечно, но как правильно кто-то заметил, все это пишется быстро и это главное.

Да, я знаю, никак руки не доходят попробовать. В данный момент я использую superlu и umfpack 5.1, также имеются собственные наработки, которые на очень больших матрицах работают даже лучше.

> такие задачи должны решать предметники умеющие немного программировать

Ничего хорошего из этого не получается. Такие программы, которые пишут эти ваши «предметники» выглядят как ночной полёт фантазии пьяного первокурсника. Нормальный вариант — специалист пишет набросок в каком-нибудь matlab'е, ковыряет алгоритм, а потом уже нормальный программист реализовывает финальный вариант.

вы так хотите мой комментарий по поводу LAPACK?

он по прежнему на обычной десктопной системе не нужен, потому что его заменили на Clapack :)
>=sci-libs/clapack-3.2.1-r3

и никто зависимости менять не станет из-за выхода новой версии lapack,

для специфичных задач - возможно, для , что называется, «хомячковой» системы можно и обойтись пока и дальше.

clapack правда скомпонован с blas , так что все равно фортран никуда не делся :)

> Такие программы, которые пишут эти ваши «предметники» выглядят как ночной полёт фантазии пьяного первокурсника.

Может быть, зато они делают _что надо_, а не изображают бурную деятельность.

Нормальный вариант — специалист пишет набросок в каком-нибудь matlab'е, ковыряет алгоритм, а потом уже нормальный программист реализовывает финальный вариант.

А может «нормальному программисту» лучше предмет подучить, а не быть всю жизнь невеждой?

Проблема исключительно в постановке задачи, а само программирование не ахти какое сложное.

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

И того: разработка бизнес-приложений - это разработка с эволюционирующими требованиями.

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

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

А написание считалок - это примитивщина.

специалист пишет набросок в каком-нибудь matlab'е, ковыряет алгоритм,

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

> на обычной десктопной системе не нужен, потому что его заменили на Clapack :)

CLAPACK. An f2c'ed conversion of LAPACK.

Говорить, что LAPACK заменили на CLAPACK как бы некорректно, ибо CLAPACK _полностью_ сделан из LAPACK.

никто зависимости менять не станет из-за выхода новой версии lapack,

Новый CLAPACK может и не появиться из-за доступности нормального интерфейса к C ;)

посмотрим, из десктопных приложений clapack (и blas) сейчас хочет digikam, а так можно было бы обойтись и без компилятора фортрана

> Может быть, зато они делают _что надо_

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

А может «нормальному программисту» лучше предмет подучить, а не быть всю жизнь невеждой?

Вы поймите, что программист пять лет учит одни дисциплины, «предметник» — другие. Не надо пытаться заставлять физиков программировать, а программистов решать физические задачи. Не выйдет у вас ничего интересного.

> CS-разложение!

Это то, что происходит с людьми, когда они много играют в контрстрайк?

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

Безусловно, так как ТЗ формируется во время разработки. Причём подчас даже модели недостаточно для осознания что же необходимо. Но по сути дела процесс весьма тривиален.

А написание считалок - это примитивщина.

Это вы просто примитивные считалки писали.

> Не надо пытаться заставлять физиков программировать, а программистов решать физические задачи.

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

cool story, bro

> cool story, bro

Это будущее. Так что становись предметником или смирись.

>Дело в том, что физика много сложнее прикладного программирования, поэтому физик в состоянии изучить немного нужного программирования...

Полностью соглашусь. Тем более что время программирования физической задачи это в среднем около 10-20% всего времени что тратится на решение конкретной задачи.

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

PS: Всегда было смешно смотреть на таких идиотов.

Смотри не подавись от смеха. Тебе сказали, что в достаточном большинстве случаев в научном прикладном программировании практически не нужны технологии, которыми владеет дипломированный программист. ООП тут практически не встречается (а если и есть, то очень простое). Математика - напротив, - намного выше того уровня, который сразу понятен среднему программисту.

Че ты передо мной оправдываешься? Мне пофиг кто там круче программер, математик, бугалтер или дворник. Не поработав в других областях, вы дурни думаете что везде легко кроме как в вашей профессии.

PS: Такие дибилы как вы, только позорят свои профессии.

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