Один уважаемый программер как-то заявил следующее (давно было, текст примерный):
«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…».
Вопрос: может ли точность зависть от языка?
И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка? A2>И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
A2>Заранее СПАСИБО!!!
Ну, не на персональных, а на нормальных компьютерах фортран и сейчас рулит. Несколько книжек Бартеньева, одна из которых тому подтверждение.
По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, не на персональных, а на нормальных компьютерах фортран и сейчас рулит. Несколько книжек Бартеньева, LVV>одна из которых тому подтверждение. LVV>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Хотя сам по себе язык страшненький.
Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII).
А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов...
Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, что за
DO 1 I=1,100,1
F(I)=G(I)+H(I)
1 CONTINUE
скрывается векторная операция F = G+H. А ведь цикл можно записать десятком разных способов. В результате автор программы должен знать, как писать код, чтобы его можно было оптимизировать.
Здравствуйте, Кодт, Вы писали:
К>Хотя сам по себе язык страшненький. ...
К>Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, ... А ведь цикл можно записать десятком разных способов. ...
Здравствуйте, achp, Вы писали:
К>>Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, ... А ведь цикл можно записать десятком разных способов. ...
A>Я попробовал об этом написать здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=89410&only=1
Здравствуйте, LaptevVV, Вы писали:
LVV>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Интересно, а в чем сложность перевести эти библиотеки на другие языки?
Здравствуйте, Кодт, Вы писали:
К>Дело не в абстракциях и выразительной мощи.
Да нет же, именно в них.
К>И Фортран, и С++ — языки для скалярных вычислений. А математикам часто нужны векторные и матричные.
И Фортран и Си++ могут полагаться на специфичные для платформы библиотеки с объектным кодом, невыразимым на самих этих языках.
К>Фортран вообще вырос из макроассемблера для какой-то древней IBM. Вот если бы он начинался от Крея — было б по-настоящему интересно.
Не было бы. Есть ведь уйма "приспособлений" Фортрана для разных аппаратных платформ с оптимизацией специфических операций. Почему они все не прижились?
Причина в том, что хочется иметь язык а) универсальный и не замкнутый на конкретную платформу, б) способный использовать специфику отдельных платформ. Эти два требования состоят в конфликте друг с другом.
Борьба с этим конфликтом может быть либо механической, либо диалектической , то есть — либо унификация, либо выделение абстракций.
То есть, если производится сложение векторов, то его так и нужно назвать в библиотеке — сложением векторов (ввести абстракцию), а не писать цикл. Реализация, которой доступен векторизующий процессор, может использовать эту особенность платформы, а другая реализация честно выполнит цикл.
Си++ дает нам возможнось выделить и назвать абстракцию, Фортран — нет.
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка? A2>И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
A2>Заранее СПАСИБО!!!
IMHO, востребован только для поддержки древнего наследия в виде огромных отработанных библиотек. То, что он сколько-нибудь быстрее С на ПК на современных компиляторах — миф. Про Большие Машины ничего не скажу, в них не разбираюсь...
Я когда-то проводил элементарное сравнение (вычисление интеграла), наслушавшись таких программеров, но значимой разницы не обнаружил (С был слегка быстрее ). А уж насчет точности... Это, скорее, вопрос реализации алгоритма, а не конкретного языка.
Мы используем C++ для численного моделирования и ничуть об этом не жалем
Полность согласен с achp
Пункт 3 обязательных правил запрещает излишнее цитирование и требует оставлять в ответах только критичные для понимания цитаты.
Обратите на это внимание.
Здравствуйте, Socrat, Вы писали:
S>Что-то я не понял. Неужели абзац — уже слишком много для цитирования? Или он не относится к задаваемому вопросу?
Лишние цитаты в этом сообщении были удалены модератором, по-видимому. Поэтому к этому сообщению претензия уже не относится.
Но требование соблюдать правила относится ко всем сообщениям. К сожалению, в своих ответах ты иногда этим пренебрегаешь.
Это интересно, спасибо!
Но меня настораживает следующее (цитата из статьи):
Размерность массива, предназначенного для хранения расчетных значений первого теста, выбрана равной 96 x 96. При 4-байтовой длине элементов этот массив займет в оперативной памяти 36 KB, что примерно в 1,8 раза меньше, чем размер кэш-памяти L2 процессора VIA C3 (64 KB), и в 3,6 раза меньше, чем L2-кэш у Celeron Coppermine (128 KB). Такое соотношение и особенности алгоритма обеспечивают благоприятные условия для эффективного использования кэш-памяти в данном тесте.
Хорошо, если приходится работать с такими массивами А если они имеют размерность ~1*10^8(общее число ячеек)? Тогда, пожалуй, в кэш не поместится. И какие будут результаты в этом случае? Учитывая, что скорость обмена с памятью практически одинаковая для всех компиляторов, разница в 30% Intel C++ vc Fortran превратится в нечто совсем мифическое.
Наверное есть класс задач, где все данные удается запихать в кэш, вот только мне с ними работать не приходится.
Потом, реализация алгоритмов не преведена. Вряд ли, конечно, там что-нибудь сделано некорректно, но все же...
Думай, прежде чем родиться в этой сказочной стране!
(с) Антон Духовской
Здравствуйте, Комаров Иван, Вы писали:
КИ>Хорошо, если приходится работать с такими массивами А если они имеют размерность ~1*10^8(общее число ячеек)? Тогда, пожалуй, в кэш не поместится. И какие будут результаты в этом случае? Учитывая, что скорость обмена с памятью практически одинаковая для всех компиляторов, разница в 30% Intel C++ vc Fortran превратится в нечто совсем мифическое.
Безотносительно к тесту, есть забавный факт, что к памяти можно по разному обращаться. Известно, например, что линейное чтение не является наиболее эффективным и позволяет достичь разве что 40%-50% процентов от максимального throughput'а.
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка?
Может.
Дело в том, что вообще говоря, в компьютерных вычислениях некоторые правила арифметики выполняются не совсем точно. Например, a*(b+c) не обязательно окажется равным a*b+a*c. Это происходит из-за ошибок округления. Так вот, в стандарте Фортрана этому уделено особое внимание, прописано как должен себя вести компилятор, и как следствие, вычисления чуть точнее...
Здравствуйте, Socrat, Вы писали:
LVV>>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
S>Интересно, а в чем сложность перевести эти библиотеки на другие языки?
Сложность в том, что в то время, когда жил фортран, культуры программирования не существовало.
На фортране писали еще хуже, чем на перле сейчас. Процедуры в !сотни килобайт! не редкость. Goto был самым используемым оператором. Имена переменных сводились к двум-трем буквам.Структур данных не было, использовались массивы.Копипейст это была основная и почти единственная парадигма пррограммирования.
Авторы того кода были чаще всего хрошими инженерами или математиками, но , к сожалению, естественная уыль населения сделала свое черное дело.
Чтобы перевести программу с фортрана например на С++ нужно.
1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.
2. Изучить теорию, а лучше описание алгоритма.
3. Переименовать все переменные по-человечески.
4. Разобраться с таким кодом
5. Написать юниттесты на все функции с учетом самых редких, вырожденных случаев.
6. Теперь можно написать несколько врапперов или произвести рефакторинг кода, на кажом этапе тестируя, тестируя и еще много раз тестируя.
Если выбираете рефакторинг, то нужно найти несколько человекомесяцев в пересчете на мегабайт кода.
Это дорого ! Но зате есть плюс — если алгоритм уникальный, то моджно быть уверенным, что он до сих пор уникальный Чаще всего используют врапперы всякие.
Но даже сейчас MS Visual Fortran рулит. Мне посчастливилось поработать с кодом, где добрый десяток мегабайт кода именно на Фортране. Насколько ме известно, тот проект еще жив !
PE>Авторы того кода были чаще всего хрошими инженерами или математиками, но , к сожалению, естественная уыль населения сделала свое черное дело.
PE>1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.
Перекуём баги на фичи!
, то есть — либо унификация, либо выделение абстракций.
То, что он сколько-нибудь быстрее С на ПК на современных компиляторах — миф. Про Большие Машины ничего не скажу, в них не разбираюсь... 
). А уж насчет точности... Это, скорее, вопрос реализации алгоритма, а не конкретного языка. 
