Здравствуйте, oRover, Вы писали:

PE>>1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.

R>надо сделать русско-белорусский словарь на РСДН

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

Здравствуйте, Кодт, Вы писали:

К>Хотя сам по себе язык страшненький.
Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/
К>Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII).
К>А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов...
В книжке ООП в действии Тимоти Бадда есть просто великолепный пример использования АПЛ на задаче, на которой фортран просто загнулся! Почитайте — классное чтиво!
Помнится еще IBM пыталась АПЛ как-то поддерживать и по этой системе даже книжка была — не помню авторов.

Здравствуйте, Socrat, Вы писали:

S>Интересно, а в чем сложность перевести эти библиотеки на другие языки?
1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать.
2. Знатоки других языков не знают фортрана. И не стремятся узнать.
3. Знатоки языков — не знают численных методов. И не стремятся узнать.
4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Кодт, Вы писали:

К>>Хотя сам по себе язык страшненький.
LVV>Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/

С чем-чем?

К>>Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII).
К>>А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов...
LVV>В книжке ООП в действии Тимоти Бадда есть просто великолепный пример использования АПЛ на задаче, на которой фортран просто загнулся! Почитайте — классное чтиво!

Мне шеф рассказывал, что в ЦНИИ кораблестроения им. Крылова была французская ЭВМ с АПЛ на борту.
Так вот, библиотека подпрограмм к ней была оформлена в виде перекидного календаря. Слева на развороте — подпрограмма в несколько строчек, сопроводиловка к ней, а справа — фото женщин. Для подъёма, тыскыть, энтузиазма.

LVV>Помнится еще IBM пыталась АПЛ как-то поддерживать и по этой системе даже книжка была — не помню авторов.

Я в руках держал интерпретатор АПЛ для IBMPC. Больше всего затрахивал способ ввода всех этих кружков с точками.
Плюс убойная графика чб 640*200.

Когда в институте работали с матлабом, моя душа плакала. Ну почему нельзя было ТОГДА (в 60-е годы) ввести такой удобный аскишный синтаксис?!

Здравствуйте, LaptevVV, Вы писали:

LVV>1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать.

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

LVV>2. Знатоки других языков не знают фортрана. И не стремятся узнать.

Еще бы, ведь у фортрана-77 (про -90 уже не в курсе) обратная совместимость чуть ли не с фортран-II, а это, извините, вообще макроассемблер для IBM-360!
Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.

LVV>3. Знатоки языков — не знают численных методов. И не стремятся узнать.
LVV>4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.

Здравствуйте, Кодт, Вы писали:

LVV>>Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/
одного компьютера на другой.
К>С чем-чем?

К>Мне шеф рассказывал, что в ЦНИИ кораблестроения им. Крылова была французская ЭВМ с АПЛ на борту.
К>Так вот, библиотека подпрограмм к ней была оформлена в виде перекидного календаря. Слева на развороте — подпрограмма в несколько строчек, сопроводиловка к ней, а справа — фото женщин. Для подъёма, тыскыть, энтузиазма.
К>Я в руках держал интерпретатор АПЛ для IBMPC. Больше всего затрахивал способ ввода всех этих кружков с точками.
К>Плюс убойная графика чб 640*200.
К>Когда в институте работали с матлабом, моя душа плакала. Ну почему нельзя было ТОГДА (в 60-е годы) ввести такой удобный аскишный синтаксис?!
Да, по мощности конструкций — наверное ни один язык не сравнится. Но по синтаксису — это ж компьютерная стенография! Помнится, читал в какой-то книжке: один из китов признался, что расшифровывал 4 строчки на АПЛ около 4 часов!

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, LaptevVV, Вы писали:

К>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.

Я согласен.

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Socrat, Вы писали:

S>>Интересно, а в чем сложность перевести эти библиотеки на другие языки?
LVV>1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать.
LVV>2. Знатоки других языков не знают фортрана. И не стремятся узнать.
LVV>3. Знатоки языков — не знают численных методов. И не стремятся узнать.
LVV>4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.

Как-то читал я книгу по авторегрессионному анализу. Там все примеры были написаны на фортране. Перевод на C++ не вызывал никаких трудностей.

Здравствуйте, Socrat, Вы писали:

S>Как-то читал я книгу по авторегрессионному анализу. Там все примеры были написаны на фортране. Перевод на C++ не вызывал никаких трудностей.

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

К>>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.

S>Я согласен.
И табуретками швыряться не будешь?!

Здравствуйте, User99, Вы писали:


К>>>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.

S>>Я согласен.
U>И табуретками швыряться не будешь?!

А у меня их нет.

А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...

Здравствуйте, Larm, Вы писали:

L>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...
Уже все давно написано.

Здравствуйте, Larm, Вы писали:

L>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...

С чего бы это?

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Кодт, Вы писали:

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

К>  DO 1 I=1,100,1
К>  F(I)=G(I)+H(I)
К>1 CONTINUE
К>

К>скрывается векторная операция F = G+H. А ведь цикл можно записать десятком разных способов. В результате автор программы должен знать, как писать код, чтобы его можно было оптимизировать.
В FORTRAN-90 именно так и можно записать сложение масивов, а еще можно записать b = MAX(A) и в b будет максимальное значение из массива
И для разных архетектур это будт обрабатываться по разному. И вообще в 90 сделан большой упор использование паралельности.
А еще введена перегрузка функций. Так что язык развивается, и значит это кому-то нужно

Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, Larm, Вы писали:

L>>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...

Ш>С чего бы это?

Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )

Здравствуйте, Larm, Вы писали:

L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )

Ну не 20...30%, но 10..15 однозначно.

Здравствуйте, Larm, Вы писали:


L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,...
Угу. Конечно.
L> А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )
Вот фомы неверующие... Неправда это все. Во-первых, в комплексных числах никаких виртуальных функций быть не может. Ок, остались только статические. Далее, передача this сама по себе ничего не стоит. "Получение доступа к полям" — тоже. Что, кто-то искренне полагает, что там кто-то что-то в стек будет складывать? Или что Fortran это сделает как-то намного быстрее? На практике все элементарный функции инлайнятся, благодаря чему всякие штуки типа вычисления корня из суммы квадратов модулей практически невозможно ускорить даже ручным ассемблерным кодом.
В общем, я бы рекомендовал перед тем как делать подобные заявления, просто натравить дизассемблер на результат работы С++ компилятора со включенной оптимизацией.

Я так думаю, что сила Фортрана исключительно в хорошо проработанных библиотеках математики. В некоторых местах там наверное можно даже встретить глобальные оптимизации. ООП здесь совершенно ни при чем.

Здравствуйте, Larm, Вы писали:

L>Здравствуйте, Шахтер, Вы писали:

Ш>>Здравствуйте, Larm, Вы писали:

L>>>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...

Ш>>С чего бы это?

L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )

Не будет ничего вызыватся. Компилятор встроит код в точку вызова. Никакой разницы с Fortran ом просто не будет. Вообще, оптимизация кода практически не зависит от языка. Если оптимизатор написан качественно, то результаты будут одинаковыми.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Шахтер, Вы писали:

Ш>Вообще, оптимизация кода практически не зависит от языка.

Все-таки зависит. Конечно, на уровне комплексных чисел, никакой разницы нет, но, тем не менее, разные свойства языков допускают/упрощают разные оптимизации.

FORTRAN благодаря ограниченности языка допускает меньше возможностей для data aliasing, что позволяет большее количество оптимизаций при манипуляции данными, чем например, в C. В последнем стандарте C, C99, например, ввели специальное ключевое слово, restricted, чтобы уровнять шансы для оптимизиции с FORTRAN'ом. В C++ ситуация другая. Высокоуровневые вычислительные библиотеки такие как Blitz++ надежно энкапсулируют данные, работать с указателями нет нужды, и компилятор может сделать aliasing analysis.

FORTRAN 95 поддерживает матричные операции, которые компилятор может перевести в соответствующие multimedia инструкции современных процессоров. Для C и C++ оптимизатор должен быть достаточно нетривиальным, чтобы распознать такие ситуации, хотя это тоже возможно и делается.

В тоже время у C++ есть одно приемущество для проведения глобальных оптимизаций. Дело в том, что source code библиотек обычно доступен в следствие повсеместного использования шаблонов. В FORTRAN'е же библиотеки представляют заранее скомпилированные модули, которые к тому же должны быть вызываемы из C, поэтому возможностей таких оптимизаций меньше.

Насчет комплексных чисел скажу отдельно. Если кто читал Липпмана "C++ Object Model", то там описывается случай сравнения эффективности C++ и FORTRAN при работе с комплекными числами. Сначала версия C++ работала в два раза медленнее. И проблемма была в ... избыточном вызове конструкторов копирования. Как только это было выяснено и устранено производительность обеих программ стала идентичной.