Кружок любителей Фортрана

[Maslov]

r-aax в сообщении #396416 писал(а):

Фортран как язык и жив-то ещё потому, что имеет именно такие преимущества перед остальными: позволяет выжимать больше на расчётных приложениях.

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

Вот в этой теме обсуждалось: Фортран

[r-aax]

Maslov в сообщении #396541 писал(а):

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

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

[Eiktyrnir]

r-aax писал(а):

... фортрановские версии процедур, которые я переписывал на си...

На самом деле сейчас все гораздо проще - есть f2c.

Munin писал(а):

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

Почему вы так считаете, что язык С++ настолько хорош, что им можно ограничится?!
Вот к примеру я считаю, что у Fortran-а имеется ряд некоторых преимуществ по сравнению с C++. Даже более того я вам скажу - имеются некоторые причины более низкой эффективности программ на языке С++ по сравнению с Fortran-ом.
Например, при выполнении операций с массивами для того, чтобы сохранить естественную нотацию, в С++ приходится использовать перегрузку операций, например:
$z=w+x+y$
где $w$, $x$, $y$ и $z$ являются одномерными массивами. Перегруженные операции в С++ всегда выполняются попарно. При вычислении выражения суммы трех векторов создаются, два временных массива и три цикла. В этом случае для больших векторов проигрыш в производительнотси, по сравнению с Фортраном, может быть в $2-3$ раза, а для маленьких векторов - почти на порядок, так как в этом случае преобладают потери на размещение временных объектов. (стр.391, С.Немнюгин, О.Стесик "Современный Фортран").

Munin писал(а):

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

Вот извините - но снова немогу согласится. К примеру я вот студентом был некудышным и не обладал достаточной степенью абстрактности мышления - к примеру самостоятельно разрулить язык C или C++ я не смог, а на кафедре именно по моей специальности он не преподавался, но тем не менее для меня был понятен язык Fortran с его древними обозначениями операций - буквально это был для меня продвинутый Basic и я его удачно для себя усвоил.
Да и потом, я что главное то хотел сказать - вот к примеру Mathcad решает методом Рунге-Кутта дифф уравнение довольно-таки легко - там есть пресловутая функция rkfixed, но вот Fortran требует написать от автора программы самому эту самую функцию - т.е. по сути весь процесс численного подсчета дифф. уравнения переложить на язык программы - и вы знаете, вот тогда ты наичнаешь чувствовать по настоящему и численные методы, и каким образом они представляют решение - когда именно сам от начала до конца честно пишешь весь алгоритм, не абстрагируя его. Пусть и громоздко, но что же - зато очень многое понимаешь когда пишешь, тренируешь тоже самое внимание свое (попробуй не закрыть скобку в Фортране - и потом ищи её ). Да и таже графика мне более понятна (лично мне) написанная именно на Фортране. Так что же теперь мне как некудышному студенту - не понимающему высокие языки совсем-совсем не программировать? Нет. Я буду. Как могу.

Munin писал(а):

...С таким подходом стоит писать на ассемблере.

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

Munin писал(а):

Кстати, в вашем примерчике хорошо бы было подсчитывать СКО и фактическую погрешность, для наглядности Монте-Карло.

Прощу прощения - расшифруйте, что есть СКО?

Munin писал(а):

Ну и вообще в смысле подсчёта $\pi$ через Монте-Карло - больше впечатляет бросание иголки.

Игла Бюффона? Кстати хорошая идея. В свободное время займусь этим вопросом.

[Xaositect]

Eiktyrnir в сообщении #396723 писал(а):

при выполнении операций с массивами для того, чтобы сохранить естественную нотацию, в С++ приходится использовать перегрузку операций, например:
$z=w+x+y$
где $w$, $x$, $y$ и $z$ являются одномерными массивами. Перегруженные операции в С++ всегда выполняются попарно. При вычислении выражения суммы трех векторов создаются, два временных массива и три цикла. В этом случае для больших векторов проигрыш в производительнотси, по сравнению с Фортраном, может быть в $2-3$ раза, а для маленьких векторов - почти на порядок, так как в этом случае преобладают потери на размещение временных объектов. (стр.391, С.Немнюгин, О.Стесик "Современный Фортран").

Ну это очень уж сильное утверждение. Даже я, человек, толком в C++ не разбирающийся, представляю, что надо сделать, чтобы временного массива не создавалось: нужен отдельный класс Sum со ссылками на несколько векторов и итератором, возвращающим сумму соотв. элементов, и операторы сложения двух векторов с результатом Sum, Sum и вектора с результатом Sum и присваивания vector = Sum. Получится, скорее всего, медленнее, чем в фортране, но ИМХО не настолько (тут не специалист, не уверен. Но временного вектора точно не будет).

[Circiter]

2Xaositect

Цитата:

Получится, скорее всего, медленнее, чем в фортране, но ИМХО не настолько (тут не специалист, не уверен. Но временного вектора точно не будет).

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

[Munin]

Maslov в сообщении #396541 писал(а):

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

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

Eiktyrnir в сообщении #396723 писал(а):

Почему вы так считаете, что язык С++ настолько хорош, что им можно ограничится?!

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

Eiktyrnir в сообщении #396723 писал(а):

Перегруженные операции в С++ всегда выполняются попарно. (стр.391, С.Немнюгин, О.Стесик "Современный Фортран").

Это не совсем так. В современном C++ в случае inline-реализации перегруженной операции компилятор имеет право применять очень серьёзную оптимизацию, в том числе и отказываться от попарного выполнения перегруженных операций с базовыми типами. (С пользовательскими типами, непрозрачными для компилятора, семантика имеет приоритет перед оптимизацией.)

Eiktyrnir в сообщении #396723 писал(а):

К примеру я вот студентом был некудышным и не обладал достаточной степенью абстрактности мышления - к примеру самостоятельно разрулить язык C или C++ я не смог, а на кафедре именно по моей специальности он не преподавался, но тем не менее для меня был понятен язык Fortran с его древними обозначениями операций - буквально это был для меня продвинутый Basic и я его удачно для себя усвоил.

Вы подменяете пользу от обучения лёгкостью. Да, фортран может быть более понятен. Но de facto отраслевым стандартом стала система обозначений C++, и студентов необходимо знакомить прежде всего с ним (никто не говорит, что это дело лёгкое), а с другими - только по мере необходимости. В данном случае пример элементарен, и никакой необходимости нет.

Eiktyrnir в сообщении #396723 писал(а):

Да и потом, я что главное то хотел сказать - вот к примеру Mathcad решает методом Рунге-Кутта дифф уравнение довольно-таки легко - там есть пресловутая функция rkfixed, но вот Fortran требует написать от автора программы самому эту самую функцию - т.е. по сути весь процесс численного подсчета дифф. уравнения переложить на язык программы - и вы знаете, вот тогда ты наичнаешь чувствовать по настоящему и численные методы, и каким образом они представляют решение - когда именно сам от начала до конца честно пишешь весь алгоритм, не абстрагируя его.

C++ в этом отношении не лучше :-)

Зато C++ легко позволяет работать с математическими объектами, не являющимися примитивными числами: например, с векторами или тензорами. Фортран в этом отношении очень долго был единственным языком, поддерживающим комплексные числа, но здесь C++ его обогнал, и надёжно.

Eiktyrnir в сообщении #396723 писал(а):

Честно говоря я не понял этой вашей фразы

С учётом ваших представлений об ассемблере - и не могли понять. Ладно.

Eiktyrnir в сообщении #396723 писал(а):

Прощу прощения - расшифруйте, что есть СКО?

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

[Maslov]

Munin в сообщении #396887 писал(а):

Maslov в сообщении #396541 писал(а):

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

Это служило серьёзным оправданием в середине 90-х. Сегодня во-первых наработано сравнимое количество численных методов на Си

Это служит серьёзным основанием по сию пору. Даже если количество численных методов на Си и сравнимо с количеством численных методов на фортране, результат такого сравнения оказывается в пользу фортрана.
В частности, основная версия одной из самых известных библиотек численных методов NAG (http://www.nag.com) до сих пор разрабатывается на фортране:

Цитата:

The NAG Fortran Library
The largest collection of numerical algorithms commercially available

А это про сишную версию:

Цитата:

The NAG C Library
The largest commercially available collection of numerical algorithms for C

Чувствуете разницу? :)

Maslov в сообщении #396541 писал(а):

во-вторых, стала реальной автоматическая перегонка фортранных реализаций в сишные .

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

И в чём, по-Вашему, преимущество библиотеки, изначально написанной на Си, по сравнению с такой же библиотекой, написанной на фортране? (Особенно, для программистов, пишущих не на C/C++).

Munin в сообщении #396887 писал(а):

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

Не надо говорить за всех. Программа, полученная с помощью автоматического перевода, -- это другая программа, а потому требует независимого тестирования и отладки.

[Munin]

Maslov в сообщении #396933 писал(а):

Чувствуете разницу? :)

В том, что конкретно NAG тяготеет к фортрану? Чувствую.

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

Maslov в сообщении #396933 писал(а):

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

Не спорю.

Maslov в сообщении #396933 писал(а):

И в чём, по-Вашему, преимущество библиотеки, изначально написанной на Си, по сравнению с такой же библиотекой, написанной на фортране?

Я что-то говорил о существовании таких преимуществ? Я говорил совсем о другом: в использовании фортрана практически нет никаких преимуществ перед Си и C++. Кроме тех, которые уже упоминались в этой теме: особенная заточенность языка и компилятора под оптимизированные и распараллеленные расчёты.

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

Maslov в сообщении #396933 писал(а):

Не надо говорить за всех. Программа, полученная с помощью автоматического перевода, -- это другая программа, а потому требует независимого тестирования и отладки.

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

Хреновые автоматические переводчики характерны для середины 90-х. В конце 00-х доступны уже и нормальные.

[Maslov]

Munin в сообщении #396966 писал(а):

Так что надо смотреть на наиболее популярные библиотеки.

Ну да, надо смотреть.

Munin в сообщении #396966 писал(а):

Я говорил совсем о другом: в использовании фортрана практически нет никаких преимуществ перед Си и C++. Кроме тех, которые уже упоминались в этой теме: особенная заточенность языка и компилятора под оптимизированные и распараллеленные расчёты.

Говорить о преимуществах того или иного языка в отрыве от области применения вообще довольно бессмысленно. Я согласен с тем, что для разработки подавляющего большинства программ фортран существенно менее удобен (и менее распространен), чем С/C++. С другой стороны, на мой взгляд, при разработке численных методов C/C++ не имеет особых преимуществ по сравнению с фортраном.

Munin в сообщении #396966 писал(а):

Мнэ... Значит, у вас хреновый автоматический переводчик.

Да у меня уже лет 15 никакого нет. Просто не вижу смысла в подобной работе. В своё время пытался использовать f2c, но результат, мягко говоря не оправдал. А у Вас какой? :)

Munin в сообщении #396966 писал(а):

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

Ссылочку не дадите на переводчик фортран->C, который гарантирует, что все тесты дадут одинаковые результаты?
(В программировании с гарантиями вообще довольно напряженно: производители ПО, большей частью, предпочитают заявлять об отказе от гарантий)

Munin в сообщении #396966 писал(а):

Хреновые автоматические переводчики характерны для середины 90-х. В конце 00-х доступны уже и нормальные.

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

[Munin]

Maslov в сообщении #397002 писал(а):

Говорить о преимуществах того или иного языка в отрыве от области применения вообще довольно бессмысленно. Я согласен с тем, что для разработки подавляющего большинства программ фортран существенно менее удобен (и менее распространен), чем С/C++. С другой стороны, на мой взгляд, при разработке численных методов C/C++ не имеет особых преимуществ по сравнению с фортраном.

Выразительные средства помощнее - раз.
Единство языка реализации - плюс для разработки, поддержки, состава разработчиков - два.
Где-то так...

Maslov в сообщении #397002 писал(а):

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

Да, это как раз из поколения хреновых.

Maslov в сообщении #397002 писал(а):

А у Вас какой? :)

У меня, честно говоря, никакого, кроме gfortran, но вроде, к gcc front-end-ам можно прицепить back-end с трансляцией на Си.

Maslov в сообщении #397002 писал(а):

В программировании с гарантиями вообще довольно напряженно: производители ПО

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

[nestoklon]

Eiktyrnir в сообщении #396723 писал(а):

. Перегруженные операции в С++ всегда выполняются попарно. При вычислении выражения суммы трех векторов создаются, два временных массива и три цикла. В этом случае для больших векторов проигрыш в производительнотси, по сравнению с Фортраном, может быть в $2-3$ раза, а для маленьких векторов - почти на порядок, так как в этом случае преобладают потери на размещение временных объектов. (стр.391, С.Немнюгин, О.Стесик "Современный Фортран").

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

Я уже не говорю про то, что азы -- никогда не переопределять сразу оператор "+", а начинать с "+=" и им же пользоваться по возможности.
В общем, RTFM.

[Maslov]

Munin в сообщении #397009 писал(а):

Единство языка реализации - плюс для разработки

О том и речь. Поэтому если основная часть разработки -- это какие-то специфические расчёты на фортране, то с точки зрения "единства языка разработки" может оказаться более предпочтительным прикрутить front-end тоже фортране.

Munin в сообщении #397009 писал(а):

О, производители ПО - это одно. А вот контрактное программирование и тому подобные фишки - другое.

Примерно то же самое.

Munin в сообщении #397009 писал(а):

В БД-шной сфере, вроде бы, даже автоматические доказательства правильности применяют, помимо обычных тестов - настолько ответственная область.

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

[Eiktyrnir]

Munin писал(а):

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

Т.е. что-то типа $\sigma_{xy}=\sigma_{x} \sigma_{y}=\sqrt{D_{x}D_{y}}$, где $D_{x}=M(x^2)-M^2(x), D_{y}=M(y^2)-M^2(y)$?

[Munin]

Maslov в сообщении #397050 писал(а):

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

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

Eiktyrnir в сообщении #397349 писал(а):

Т.е. что-то типа

Я бы ответил, если бы знал, что в ваших обозначениях $x$ и $y$. Скорее, речь шла о $\sigma=\sqrt{M\bigl((\pi_{\mathrm{Monte-Carlo}(N)}-\pi_{\mathrm{true}})^2\bigr)}.$

[Eiktyrnir]

(Оффтоп)

Munin писал(а):

Я бы ответил, если бы знал, что в ваших обозначениях $x$ и $y$.

Да уж... лучше бы вам и не знать, что у меня тут $x$ и $y$

Munin писал(а):

Скорее, речь шла о $\sigma=\sqrt{M\bigl((\pi_{\mathrm{Monte-Carlo}(N)}-\pi_{\mathrm{true}})^2\bigr)}.$

Хм... Так это же просто корень квадратный из математического ожидание от константы (что есть константа по свойству мат.ожидания). К примеру для той выборки что в примере $N=10000000$ получается, что
$\sigma=\sqrt{M\bigl((\pi_{\mathrm{Monte-Carlo}(N)}-\pi_{\mathrm{true}})^2\bigr)}=\sqrt{M\bigl((3.14078040000000-3,14159265358979)^2\bigr)}=\sqrt{M(0,00000066)}=\sqrt{0,00000066}=0,00081$
Или я не так понял?