geany

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

// А на что вы собираетесь тысячу баксов тратить? На компьютер для установки компилятора?

штеуд за свой компилятор просит 699$ например. Если он действительно этих денег стоит - можно и потратить.

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

а библиотеки? Есть ли open source альтернативы IMSL?

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

Есть, только россыпью, в опенсорсе принято что одну задачу решает одна библиотека.

gotoblas2, как пример.

>gfortran свободный.

Ну ходят упорные слухи, что код, который генерирует Intelовский компилятор для intel или PGIшный под amd, работает всё-таки несколько быстрее. Но тут тестировать надо на конкретной задаче, там использование нелучшего алгоритма или неоптимальной библиотеки всю выгоду запросто съедает.

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

Это точно.

Кстати, фортран еще уступает сям в том, что CUDA'вского компилятора для фортрана нет :)

Замечательно. Тогда вопрос можно поставить следующим образом. Разработка будет вестись на 2х рабочих станциях, одна - только под Windows, вторая - без разницы, процессоры - Intel 8600, задача включает в себя перемножение большого количества матриц, решение дифуров и анализ рядов. Какую связку ПО можно предложить для первого раза, чтобы мы дальше знали, что нам необходимо?

CUDA использоваться не будет, если что-то и будет, то Cell BE - есть небольшой кластер на PS3.

одна - только под Windows

С этого и надо было начинать. Тогда тему сразу бы грохнули, и никому здесь ничего писать бы не пришлось!

gfortran в качестве компилятора, gotoblas2 в качестве базовой матричной математики http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ в качестве простой IDE можно geany использовать. Если потом будет желание, можно на Intelовскую связку соскочить всегда, разные имплементации BLAS совместимы друг с другом в пределах погрешности.

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

[немного офтоп]
Скажите, а почему вы решили на фортране писать? Ведь существует 100500 удобных ЯП.
Берем те же C+GSL. Получаем и ряды, и матрицы, и дифуры...
[/немного офтоп]

эм... ну вообще говоря geany intel fortran compiler и gfortran есть под обе платформы.

Так а почему именно фортран-то выбрали? Может, Ада какая-нибудь больше подойдет? ;)

[немного офтоп]

Скажите, а почему вы решили на фортране писать? Ведь существует 100500

удобных ЯП.

Берем те же C+GSL. Получаем и ряды, и матрицы, и дифуры...

[/немного офтоп]

потому что мы бородатые дядьки в больших круглых очках, которые заправляют свитер в джинсы (%

потому что руководитель знает фортран и PL и не знает C, а из этих двух только фортран дышит.

А не послать ли вам руководителя Неужели руководитель - такой упертый старый баран? Или кроме него у вас никто в математике и программировании вообще не разбирается?

Intel® Parallel Studio XE 2011 for Windows or Linux.

* Intel C++ Compiler Professional Edition
* Intel Fortran Compiler Professional Edition
* Intel Integrated Performance Primitives
* Intel Threading Building Blocks
* Intel Math Kernel Library
* Intel VTune Amplifier XE
* Intel Inspector XE

>Бюджет - не более 1000$

Цены разных вариантов.

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

Интересный вопрос.
Даже сам таким задавался.
Мой вариант ответа:
Как только что начнете считать долго , серьезно и качественно
сразу снобизм о fortran пропадает и это становится как «старый конь что борозды не портит».

«Лень - двигатель прогресса»
Под фортран большой обьем вылизанного кода и либ. Работают по 30 ...40
лет и жрать не просят.
Переписывание этого добра на с или с++ ничего нового не даст, кроме головных болей и вопросов совместимостей компиляторов и платформ.

>Переписывание этого добра на с или с++ ничего нового не даст, кроме головных болей и вопросов совместимостей компиляторов и платформ.

+ ещё не известно, насколько правильно это всё портанут.

http://www.linux.org.ru/forum/development/5571644 тотже вопрос — юзай поиск.

Слинковать фортрановские библиотеки, которым 30--40 лет, хоть с C, хоть с лиспом проблем не составит. Но писать на нём что-то новое сейчас --- это утончённое извращение.

Кстати, поддержка старого кода на фортране это зачастую тот ещё BDSM. Особенно если код писался «физиками для физиков», для которых характерно знание только фортрана (причём исключительно 77) и ничего другого, и плевать они хотели на разделение программы на независимые логические единицы. Это я намекаю автору темы, что если руководитель знает только фортран и до сих пор не удосужился выучить даже C, то он вряд ли компетентен в вопросах связанных с программированием (не путать с численными методами), и его решения следует тщательно обдумывать самостоятельно прежде чем приступать к воплощению.

Благодарю.

Тогда какой профит от С я получу по сравнению с фортом? Для меня все процедурные языки программирования на одно лицо если честно, довольно плотно работал только с С и Pascal

>Тогда какой профит от С я получу по сравнению с фортом


Ну, будет о чем поговорить на форумах и перетереть новые фишки, ключики и регрессы в gcc.
Для многих «быть в струе» это как основное.))

Слинковать фортрановские библиотеки, которым 30--40 лет, хоть с C, хоть с лиспом проблем не составит. Но писать на нём что-то новое сейчас --- это утончённое извращение.

Это точно. А учитывая то, что все фортрановские библиоткеки 20-и более лет существуют уже для любых ЯП, смысла его использовать нет. Тем более, что современные алгоритмы вряд ли реализуют на фортране. Так что, все равно придется самому что-то писать... А на С/С++ есть вероятность найти готовую библиотеку.

>Тем более, что современные алгоритмы вряд ли реализуют на фортране.

Эээ, а что это такое «современные алгоритмы» применительно к числодробилкам ?

А учитывая то, что все фортрановские библиоткеки 20-и более лет существуют уже для любых ЯП, смысла его использовать нет.

Atlas - а подскажите мне аналог с хорошим послужным списком , репутацией и на открытых исходниках.

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

> да не аналог, а то же самое,

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

Свободный компилятор Fortran входит в состав почти любого дистрибутива Linux. Поддерживаются и новые стандарты языка. Лично я не любитель IDE. Но если вы так хотите, можно воспользоваться Eclipse:

http://www.eclipse.org/photran/

Photran - An Integrated Development Environment and Refactoring Tool for Fortran

> Тогда какой профит от С я получу по сравнению с фортом?

Программы редко состоят из одних численных расчётов. Есть ещё ввод-вывод с чтением кучи данных, записанных в некоем формате. Если формат не проектировался с учётом того, что его будут читать из фортрана, это может стать серьёзной проблемой, потому что писать парсер на фортране с его практической невозможностью оперировать строками неопределённой длины чрезвычайно трудно. Если для обмена данными используются бинарные файлы, это вообще может превратиться в геморрой, ибо бинарные файлы, сгенерированные одной и той же программой на фортране, скомпилированной разными компиляторами, отличаются и между собой не совместимы. Ещё есть модель, которую может быть удобнее описывать в терминах объектов, замыканий, DSL или всё это сразу, чем в виде массивов чисел. В фортране проблемы даже с выделением памяти и его знаменитыми динамическими массивами --- без изрядных костылей выделенную память в функции передать наверх невозможно, всё должно быть уничтожено прямо в этой функции. А при увеличении длины динамического массива его всегда приходится копировать в лучшем случае один раз, что приводит к невменяемым тормозам при попытке считать входные данные неизвестного зараннее размера. В общем, если у вас что-то сложнее, чем «считать матрицу из текстового файла, в котором в первой строке записаны её размерности, посчитать её определитель и выдать на stdout», то лучше взять как минимум связку Fortran + «язык уровня не ниже C». Я бы всерьёз рассмотрел лисп (SBCL), ибо у вас всё равно основная нагрузка будет уходить в фортрановскую библиотеку, и в результате вы бы быстро получили реактивную систему, которую удобно отлаживать и легко дополнять... но вы не знаете лиспа, увы.

Эээ, а что это такое «современные алгоритмы» применительно к числодробилкам ?

Вкратце. И это только цветочки. Зачастую бывают нужны очень сложные алгоритмы, о которых лет 10 назад вообще не догадывались...

Atlas - а подскажите мне аналог с хорошим послужным списком , репутацией и на открытых исходниках.

А что там за функционал?

Вообще у меня сложилось мнение, что многие отметившиеся в этой ветке не представляют, что такое современный Fortran. Ребята, это не Fortran 77. В этом вашем C, например, можно ли удобно (в плане синтаксиса) работать с числами произвольной точности?..

> И это только цветочки. Зачастую бывают нужны очень сложные алгоритмы, о которых лет 10 назад вообще не догадывались...

А причем тут ваши заморочки c opengl по графике и фортран ?
Это совсем разные области приложения ЯП.

Астрономия, небесная механика, расчеты устойчивости электрических сетей ...
это уже сферы классических применений фортрана.

В этом нашем лиспе можно. И даже скорость будет не меньше. А что, в этом вашем современном фортране уже таки можно передавать выделенную память наверх? Вот пример того, как делаются связанные списки: http://fortranwiki.org/fortran/show/gen_list Прошу обратить особенно пристальное внимание на «синтаксическое» «удобство» работы. Можно сделать лучше?

>Прошу обратить особенно пристальное внимание на «синтаксическое» «удобство» работы. Можно сделать лучше?

Можно, в пистоне уже сделали.
Парадокс от Разума:
Быстродействие программы обратно пропорционально удобству для программиста.

лисп и «синтаксическое» «удобство» - это нонсенс какой-то, дорогая операция на мозгах.))

А причем тут ваши заморочки c opengl по графике и фортран ?

Вы описание проблемы по ссылке внимательно читали? Там про openGL ничего нет. Только обыденные математические задачи: распознавание изображений, аппроксимация, фильтрация и т.п.

Астрономия, небесная механика, расчеты устойчивости электрических сетей ...

Учитывая то, что с CUDA фортран работать не умеет, он явно проигрывает по скорости тому же С. Что лучше: ждать полдня (а то и больше), пока у вас одна картинка обработается, или же подождать всего лишь минут 15-20?

>Учитывая то, что с CUDA фортран работать не умеет,

первый же втык в google

http://www.pgroup.com/resources/cudafortran.htm

http://www.nvidia.ru/object/cuda_fortran_ru.html
Fortran – это ключевой язык программирования, используемый разработчиками, работающими с высокопроизводительными компьютерными вычислениями. Этот язык был выбран для программирования во многих прикладных областях, включая гидрогазодинамику (например, прогнозирование погоды и моделирование океана) и проекционно-разностный анализ.
....

AMD Core Math Library for Graphic Processors (ACML-GPU)
http://developer.amd.com/gpu/acmlgpu/pages/default.aspx
New for v1.1:

* Support for the latest AMD graphics cards
* GPU acceleration of complex matrix multiply BLAS routines
* libCALBLAS sample source

еще вопросы ?

Вы описание проблемы по ссылке внимательно читали? Там про openGL ничего нет.

Ах простите
GL_TRIANGLE_STRIP , GLubyte - ну ничего общего с openGL не имеют.

Жду новых придирок с словам.))

fixed: с словам. -> к словам.

первый же втык в google

Ладно, значит, оно еще шевелится.

Ах простите GL_TRIANGLE_STRIP , GLubyte - ну ничего общего с openGL не имеют.

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

Вы хотите меня уверить, что ничего нет в google по запросу fortran + triangulation ?

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

google: fortran + triangulation

Результатов: примерно 37 400

google: C + triangulation

Результатов: примерно 1 120 000

И в этой уйме еще надо попытаться что-нибудь нужное найти. Я, например, пока не нашел. Но эта проблема пока что отложена в долгий ящик, как вернусь к ней - поищу получше...

ну и аргументы же у вас ))

google: porno
Результатов: примерно 152 000 000 (0,19 сек.)

впечатляет ?))

Oracle Solaris Studio

>> Посоветуйте связку IDE+компиляторы.

GCC-Fortran + NetBeans C/C++

Бедный-бедный дядя. Как же тебе не повезло. Может стоит подумать о смене места обитания?

>Астрономия, небесная механика, расчеты устойчивости электрических сетей ...

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

по сравнению с фортом?

ликбез: форт --- это совсем другой язык.