Забавно, однако. Даже среди тех, кто заходит в тему, большинству FORTRAN уже не нужен.  Не помню, где то читал, что смерть ALGOL'а (PASCAL'я ?) как языка для научных и инженерных вычислений была в первую очередь обусловлена отсутствием поддержки крупных корпораций. А вот FORTRAN'у больше повезло. А мне, соответственно, меньше  - навеяно попытками чтения FORTRAN'овского кода.  Ну, да ладно, это всё оффтоп.

Cr@$h, а есть хоть сколь-нибудь достоверные данные (если такие вообще существуют  ) об эффективности FORTRAN? Т.е. бенчмарки в сравнении с C, C++, ... Просто интересно вот что. Обычно, когда "пиарять" FORTAN, скорость исполнения кода - основной аргумент. Но, что я вижу на простых тестах? Free Pascal уже в спину дышит...  

Тогда можно сразу не стандартизовывать сразу даже многие другие развивающиеся языки, не говоря уже о мастодонтах. Ada вообще не нуждается в стандартах новых, да..


Перегруженный Algol 68 по большей части.


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


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

Ту страницу лучше даже не открывать. Скажи, как ты вообще напишешь на Free Pascal программу, которая будет работать на 4-ядерном процессоре, и при этом потратишь на это меньше времени. У тебя и времени больше уйдёт на разработку до определённого процента ошибок, и работать будет дольше, а если ты пишешь не в своём гараже и твой код собираются повторно использовать, то икать будешь часто, поверь мне.

Это сообщение отредактировал(а) Cr@$h - 18.1.2009, 21:04

Код новый. Профессионализм писавших сомнения не вызывает.


Это всё - лозунги. Если можно, примеры.


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

Приведи код, приведи его на Pascal, посмотрим.


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


Всё. Pascal отстаёт в 3,5 раза где-то. Вопрос закрыт. Или скажи, как будешь распараллеливать приложение под 4 ядра.

Лады, токлько я не обязательно за PASCAL попытаюсь аналог привести.


Это сообщение отредактировал(а) kemiisto - 18.1.2009, 15:23

Хорошо, но Matlab не в счёт, мы его не касались. А с Pascal я бы тебе помог или с Delphi.

Гауссово исключение с частичным выбором ведущего элемента.
Подробности алгоритма, если интересно почитай там, где тебе удобно в Инете.


Как я и обещал, начиная с первого императивного оператора и заканчивая последним (а это цикл do), всего задействовано 12 операторных строк, if разделил, т.к. у меня такой стиль.

Не поверишь, но ты тоже знаешь Fortran, т.к. наверняка знаешь кого-то из потомков от его первых версий. Дам пояснения.

Ищется номер максимального по модулю элемента в k-ом столбце, начиная с k-ой строчки и до N (A(k:N, k)).

В элементы k:N массива Work заносятся элементы k:N строки M матрицы A.

Соответствующие элементы столбца k берутся с обратным знаком и все делятся на число work(k) (ведущий элемент).

К элементам матрицы A(k+1:N, k+1:N) прибавляются соответствующие элементы матрицы, получаемой произведением к-ого столбца (его части) A(k+1:N, k) на строку Work(k+1:N) (её часть).

Добавлено @ 18:02
Тему потом разделю.

Это сообщение отредактировал(а) Cr@$h - 18.1.2009, 18:04

Эти "простые тесты" - чушь полная. Если на всех языках писать "в стиле C++", то именно C++ и выиграет, что неудивительно.
Вот, например, n-body из этого набора тестов. За такой код на Фортране:

...программисту руки отрывать надо. В Фортране есть эффективнейшие матричные вычисления, а автор этого "шедевра" тупо скопировал структуры из C++ (судя по текстам, "базовым" языком был именно он). В результате получился медленный и неудобный для понимания код. При адекватном выборе представления данных вся эта процедура переписывается в одну строчку, которая, во-первых, скомпилируется в более производительный код, во-вторых, будет существенно осмысленней с точки зрения физики задачи.

Ну, возьмём, например, реализацию вот отсюда:


Cr@$h, только давай не будем меряться количеством строк. На том же Ruby строчек будет меньше.   Это не показатель. Хотя в случае Ruby итераторы трудно причислить к императивному стилю...

Что видно сразу, так то, что в FORTRAN матричная арифметика (и не только арифметика) есть, что называется, "из коробки". А в PASCAL нету, зато есть в PASCAL-XSC. Код на последнем не привожу, ибо несмотря на обладание двумя книжками, руки так и не дошли. А ещё эти интервальные вычисления...  Но, это ладно. 


Не помогло, я всё равно ничего не понял.  Ну и ладно. Меня больше интересует, почему же всё таки

Даже пусть и в сравнении с приведённым кодом Delphi.

Даже точки с запятой остались )  


Физику задачи я из кода не понял. А что допустимо менять там? В первом приближении хотя бы так:

Если можно изменить структуру body в двумерный массив, то я бы не то, что процедуру укоротил, сам вызов бы её свёл к строчке   

Но С-программисты не привыкли мыслить в терминах исходных задач. Просто надо привыкнуть к этому.

Добавлено через 10 минут и 40 секунд

Неет, не будем. Мы же не в детском саду в туалете.   

Неа. Её физически не записать короче, только если нет встроенной функции обмена значениями двумя массивами. И помни, мы говорили про эффективность. Ruby отдыхает. Давай честно.


PASCAL-XSC для интервальный вычислений и создавался. Они есть и в некоторых реализациях Fortran.


Шутишь? Чем меньше кода надо писать, тем меньше ошибок в нём. Любые метрики надёжности кода так или иначе содержат число строк, да и не обязательно в первой степени.

Поражён.

P.S. Оттуда больше подходит пример с LU-разложением, но не суть важно. Вывод ясен и доказан, я считаю.

Добавлено через 11 минут и 41 секунду
Параллельно по бокам наших с тобой изысканий я сократил процедуру из С++ до одной строчки.

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



Самое забавное, что в терминах исходной задачи наиболее адекватным вариантом будет именно эта одна строчка. Просто в C/C++ нет средств для такой ее реализации.

Cr@$h, BTW, а как по-твоему, оно вообще нужно (интервальные вычисления)? Интересно просто...


Я не спорю и не шучу. Я не о том спрашивал. А с этим то я согласен естественно.


Чем?


Ну...

Добавлено через 3 минуты и 22 секунды
Чтобы я убедился окончательно - надо самому "пощупать". 

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

Это сообщение отредактировал(а) Cr@$h - 18.1.2009, 20:17

Да, я заметил.  

Cr@$h, я ещё раз извиняюсь за оффтоп, устроенный в этой теме, ты бы не мог "подкинуть" ссылочку на хороший учебник по FORTRAN'у.

P.S. А почему нет подраздела FORTRAN в Красной книге? 3/4 (навскидку) вопросов касаются именно этого языка. LISP, Prolog, ...  

Это сообщение отредактировал(а) kemiisto - 18.1.2009, 20:25

Ничего страшного. По-моему, только польза. Эту тему я вообще на 5 распиливаю.. В форуме Винград Литература -- Разыскивается. Посмотри Бартеньева или Рыжикова. Когда-то сам с Бартеньева начинал.

Всему своё время. На этих выходных я провожу большую работу по чистке форума Разное и вводу в нём префиксов в темах. Как только закончу, предложение о создании форума по Fortran выдвину. В форуме Разное создам спецтему, так что все узнают. Просто не хочу спешить, нужно всё сделать грамотно и не бросать другие форумы, а я в этом году снимаю себя с должностей некоторых.

Есть, кстати, еще книга А.М.Горелик "Программирование на современном Фортране". Это, пожалуй, лучший вариант - в остальных книгах авторы очень часто либо тянут "хвосты" устаревших стандартов языка, либо ориентируются на конкретные компиляторы (как правило - далеко не самый удачный  Microsoft'овский). Впрочем, у Бартеньева и Рыжикова книги действительно неплохие.