Комментарии 125
Интересно, а бывает Visual Fortran? :)
Насколько я понимаю, важнейшее достоинство фортрана — на нём уже очень давно написано большинство необходимых в физике/квантовой химии etc. алгоритмов.
Это в том числе. Но Фортран сам по себе очень приятный язык, сделанный для людей, без этих монструзных конструкций, так свойственным современным мейнстримовым языкам. Там уже куча всего из под коробки и оно отлично работает, не надо ломать голову над никому не нужным синтаксическим сахаром.
Ну и интересный момент — ни раз бывало, что фортрановский скомпилированный код получался на 5-10% быстрее кода на Си, при этом компилятор то один и тот же (интеловский)… ну т.е. для того что бы получить такой же быстрый код на Си надо серьезно поизвращаться.
Вот и получается, что по соотношению затраты/производительность, Фортран оказывается самым оптимальным. За бугром (особенно в США) он куда более распространен чем в РФ (в РФ я бы сказал про него почти никто не знает)
Ну и интересный момент — ни раз бывало, что фортрановский скомпилированный код получался на 5-10% быстрее кода на Си, при этом компилятор то один и тот же (интеловский)… ну т.е. для того что бы получить такой же быстрый код на Си надо серьезно поизвращаться.
Вот и получается, что по соотношению затраты/производительность, Фортран оказывается самым оптимальным. За бугром (особенно в США) он куда более распространен чем в РФ (в РФ я бы сказал про него почти никто не знает)
Здесь, A, B, C – массивы некоторой размерности (допустим, 10x10x10). C = A*B даёт нам поэлементное перемножение матриц, если A и B одного размера. Для матричного умножения используется C = matmul(A,B). Почти все внутренние функции Fortran (Sin(), Exp(), Abs(), Floor(), и т.д.) принимают массивы в качестве аргументов, что приводит к простому и чистому коду. Похожего кода в C/C++ просто нет.А почему автор оригинала умалчивает о возможности введения классов и переопределении операторов в C++, с помощью которых можно записать векторные и матричные вычисления таким же простым и чистым кодом?
Он упирает на то, что в Fortran это уже и так работает, и что физики стараются поменьше программировать и побольше заниматься физикой.
Потому, что в C++ всё это можно сделать тысячей способов, разница в производительности которых может достигать нескольких порядков.
Компиляторы фортрана же предлагают достаточно производительное, унифицированное и простое в использовании решение из коробки.
Например вы можете дать коллеге код на фортране и он сразу же заработает. Можете найти на старой ленте программу написанную неизвестно кем в 1970-х и она скомпилируется с кучей ворнингов, но выдаст точный результат.
C/C++ — более универсальный вариант. Вы можете использовать одну из тысяч библиотек, или написать свой велосипед. Но будьте готовы, что у вашего друга интеграция вашего кода может занять некоторое время потому что используемые библиотеки, их версии, или формат хранения могут быть несовместимы.
Потому, с точки зрения представления алгоритмов, программы на фортране в разы более переносимы чем на любом другом языке. Язык развивался все эти годы именно в этом направлении и это работает.
А для C++ разве нельзя найти уже готовую «коробку» с хорошей производительностью и переносимостью? Чтобы без велосипеда…
Конечно можно. Но у вашего коллеги из другой организации эта коробка будет другой.
И согласно законам Мерфи, она будет несовместима с вашей.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо, что на Javascript никому еще не пришло в голову программировать алгоритмы. Потому что в Javascript для любой проблемы есть минимум 10,000 готовых библиотек, из которых 9,999 считаются устаревшими и немодными, а 1 — является слишком новой и продвинутой, и потому ни с чем другим (включая существующие среды исполнения).
С++ с хорошей переносимостью — это Java.
Относительно производительности С++ и Java — это такой огромный холивар.
Относительно производительности С++ и Java — это такой огромный холивар.
мне кажется, Java и C++ вообще некорректно сравнивать по критерию переносимости — не в этом между ними разница. Если всё же попытаться, то выходит, что есть целая куча платформ, на которых C++ код работает, а Java — нет (все, на которых не JVM), но не наоборот. Да и писать переносимый C++ код вообще не сложно, скорее наоборот, написать непереносимый C++ код — нужно ещё постараться.
Работать код С++ может и работает вот только тут важнее то чтоб код абсолютно одинаково работал. И здесь мы упираемся в различия архитектуры.
Java код не будет абсолютно одинаково работать на разных архитектурах, так что тут у Java тоже не превосходит C++. Что бы java-код работал абсолютно одинаково, нужно его писать специальным образом — эта опция доступна и для C++.
У фортратна была в науке (физике) своя ниша, но сейчас, на практике, по моим наблюдениям новый код никто (в физике) на fortran не пишет, да и старый даже иногда на C/C++ переписывают.
Ваша ссылка сама по себе не говорит не о чём. За ВСЕ пакеты для квантовой химии сказать не могу, но вот например популярнейший Gaussian написан в 1970м. CPMD и CP2K — 2000 год. Вся физическая школа связанная с разработкой QM софта сформировались в 70е годы, отсюда и фортран. Это не новый софт. Огромное количество опыта и кода накопленного в этой области исторически связанно с фортраном. Вопреки этому, новые проекты все больше пишут на C++/C. Даже новые модули старых проектов, бывает, пишут на C++. Например PSI переписали с Fortran на С++. ORCA, котрая была написана сравнительно недавно, более молодым поколением учёных — написана на C++.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите, например, в сторону SNEC (http://stellarcollapse.org/snec). Симулятор вспышек сверхновых, появилась она всего 2-4 года назад. MESA, которая моделирует эволюцию звёзд, тоже на фортране, емнип, и тоже довольно-таки «молодая»
НЛО прилетело и опубликовало эту надпись здесь
Ого!
Как много я не знал о Фортране! Это я про матричные операции.
Фортран был в институте, но я его забросил в пользу Си.
Сейчас всерьез задумался — а не вернуться ли?
И даже есть книжки по Куде оказывается.
(Загуглил — нашел «CUDA FORTRAN ДЛЯ УЧЕНЫХ И ИНЖЕНЕРОВ»).
В общем ничего не мешает попробовать.
Спасибо за статью!
— mirsev
возможности введения классов и переопределении операторов в C++,
Как ни грустно — шикарные возможности С++ используются крайне мало.
Вокруг почти все (научные сотрудники-физики) пишут разные программы обработки данных или расчетов на чистом С, не используя плюс-плюсовские плюшки.
Есть конечно библиотеки типа Blitz++, но ими тоже далеко не все пользуются. Почему? Ну потому что чего там… циклы есть, условия есть, массивы есть. Всё. Что еще надо от языка? )))
— Еще одна мысль — научные программы не предполагают длительного использования. Т.е. мы хотим что-то рассчитать — быстренько написали, посчитали, написали статью — можно переходить к новой задаче, а этот код или забросить или модифицировать под новую задачу. Т.е. типичная научная программа не предполагает долгого обдумывания структуры, а значит парадигма велосипедно-костыльного программирования оказывается вполне жизнеспособной.
— Бывают исключения — находятся герои которые минимальным коллективом создают программные комплексы которые могут соперничать с программами-монстрами типа Fluent, CFX, Comsol, и т.п… Потом этими программами пользуются разные научные группы. Но в этих коллективах как правило люди сильно уклонились от физики в сторону программирования.
Как много я не знал о Фортране! Это я про матричные операции.
Фортран был в институте, но я его забросил в пользу Си.
Сейчас всерьез задумался — а не вернуться ли?
И даже есть книжки по Куде оказывается.
(Загуглил — нашел «CUDA FORTRAN ДЛЯ УЧЕНЫХ И ИНЖЕНЕРОВ»).
В общем ничего не мешает попробовать.
Спасибо за статью!
— mirsev
возможности введения классов и переопределении операторов в C++,
Как ни грустно — шикарные возможности С++ используются крайне мало.
Вокруг почти все (научные сотрудники-физики) пишут разные программы обработки данных или расчетов на чистом С, не используя плюс-плюсовские плюшки.
Есть конечно библиотеки типа Blitz++, но ими тоже далеко не все пользуются. Почему? Ну потому что чего там… циклы есть, условия есть, массивы есть. Всё. Что еще надо от языка? )))
— Еще одна мысль — научные программы не предполагают длительного использования. Т.е. мы хотим что-то рассчитать — быстренько написали, посчитали, написали статью — можно переходить к новой задаче, а этот код или забросить или модифицировать под новую задачу. Т.е. типичная научная программа не предполагает долгого обдумывания структуры, а значит парадигма велосипедно-костыльного программирования оказывается вполне жизнеспособной.
— Бывают исключения — находятся герои которые минимальным коллективом создают программные комплексы которые могут соперничать с программами-монстрами типа Fluent, CFX, Comsol, и т.п… Потом этими программами пользуются разные научные группы. Но в этих коллективах как правило люди сильно уклонились от физики в сторону программирования.
Когда-то давно приходилось для физических расчетов оптимизировать сишную программу и разбираться в том какой код генерит компилятор для сопроцессора плавающей точки. Последующая ручная оптимизация помогла ускорить расчет в разы. Интересно было бы узнать дают ли свойства фортрана какие-то преимущества для оптимизации бинарного кода компилятором.
Для матричного умножения используется C = matmul(A,B)
Автор, ты хоть смотрел в эти исходники? Подсказка: используют ZGEMM хоть в фортране хоть в Си. И да, программы на C физики тоже пишут.
В Fortran доступ к элементам массива работает через простой синтаксис A[x,y,z], когда в C/C++ нужно писать A[x][y][z]. Элементы массивов начинаются с 1, что соответствует представлениям физиков о матрицах, а в массивах C/C++ нумерация начинается с нуля.
Ну да, если так записать 3-тензор (как массив массивов ссылок), то его ни одна библиотека с линейной алгеброй (LAPACK,BLAS) ни MPI не примет. Физики, которые их используют, конечно, не в курсе чем *double лучше ***double. (Сарказм)
Под капотом компилятор Fortran автоматически оптимизирует их передачу для повышения эффективности.
Ага, конечно, только маленькое НО:
В Fortran также есть спецификация intent, сообщающая компилятору, является ли передаваемый в функцию аргумент входным, выходным, или одновременно входным и выходным параметром. Это помогает компилятору оптимизировать код и увеличивает его читаемость и надёжность.
Да, нужно сообщить компилятору, будешь ли ты изменять массив и нужно ли его обнулять (IN,OUT,INOUT). А в C ты явно пишешь memcpy. Такие дела.
В общем, я не слышал ни об одном случае, чтобы современные студенты писали свои проекты на Fortran. Вся статья ИМХО высосана из пальца. Это я как человек, который так и не осилил Fortran говорю.
В общем, я не слышал ни об одном случае, чтобы современные студенты писали свои проекты на Fortran.
например, в ЦАГИ
в мфти, например, фортран вполне себе живет и используется
это я как студент мфти говорю
P.S. сам пишу на фортране
это я как студент мфти говорю
P.S. сам пишу на фортране
The University of Texas at Austin, Computational Electromagnetics group.
Код для решения уравнений Максвелла (интегральная формулировка)
Сам использую Fortran, конечно больше по историческим причинам. Часть кода нашей группы ведет историю со стародавних времен. Местами плююсь, местами радуюсь синтаксису языка.
До этого использовал C++. Примерно так же, местами плевался, местами радовался.
Но как только приходится много работать с матрицами и тензорами — Fortran просто чудо. Он действительно интуитивен и понятен. В C++ близко подходит только Eigen template library, однако это все равно не настолько удобно. И требуется регулярно обновлять библиотеку, в которой есть проблемы, особенно когда используется OpenMP/MPI.
На современном Fortran можно писать красивый и удобочитаемый код, однако, это не происходит потому что хорошие программисты редко программируют на Fortran, и даже примеров хорошего кода не так много, несмотря на то, что возможности к такому в синтаксисе языке присутствуют.
Код для решения уравнений Максвелла (интегральная формулировка)
Сам использую Fortran, конечно больше по историческим причинам. Часть кода нашей группы ведет историю со стародавних времен. Местами плююсь, местами радуюсь синтаксису языка.
До этого использовал C++. Примерно так же, местами плевался, местами радовался.
Но как только приходится много работать с матрицами и тензорами — Fortran просто чудо. Он действительно интуитивен и понятен. В C++ близко подходит только Eigen template library, однако это все равно не настолько удобно. И требуется регулярно обновлять библиотеку, в которой есть проблемы, особенно когда используется OpenMP/MPI.
На современном Fortran можно писать красивый и удобочитаемый код, однако, это не происходит потому что хорошие программисты редко программируют на Fortran, и даже примеров хорошего кода не так много, несмотря на то, что возможности к такому в синтаксисе языке присутствуют.
Вот так я впервые узнал, что у фортрана бывает куча и можно аллоцировать память. Мне всю жизнь хватало статически выделенной памяти.
Студентам-физикам изучать Fortran легче, чем C/C++
Я думаю, что изучать Fortran легче, чем C/C++. Fortran 90 и C очень похожи, но на Fortran писать проще. C – язык сравнительно примитивный, поэтому физики, избирающие себе C/C++, занимаются объектно-ориентированным программированием. ООП может быть полезным, особенно в крупных программных проектах, но изучать его гораздо дольше. Нужно изучать такие абстракции, как классы и наследование. Парадигма ООП очень отличается от процедурной, используемой в Fortran. Fortran основан на простейшей процедурной парадигме, более приближенной к тому, что происходит у компьютера «под капотом».
Слухи о сложности ООП сильно преувеличены. Этому можно научить любую, извините, макаку. И успешно учат. А уж физики-то поумнее будут среднестатистического кодера. Напоминаю, что речь о студентах, а не об одногодках этого самого фортрана.
У нас в отделе хорошо себя показывает связка C++ с высокоуровневым языком типа Python. Мы занимаемся как раз физическим моделированием.
Идея такая: на C/C++ пишем вычислительное ядро программы. Всё остальное пишется на Python: I/O, пользовательский интерфейс, скрипты для запуска C++ ядра, всякие предварительные расчеты, пост-обработка данных и т.д.
Здесь, конечно, квалификацию программиста надо повыше иметь, но тоже ничего архисложного нет. Python до необходимого уровня учится за два месяца, ресурсов море. С биндингом тоже разобраться можно, хотя самостоятельно будет уже не так легко.
Зато потом скорость разработки и модификации кода сильно возрастает, а удовольствие от процесса увеличивается вообще многократно.
А почему python, у которого синтаксис совершенно непохож на C, а не тот же perl?
Потому что предыдущий комментатор не совсем прав, неявно заявляя, что средний физик программирует лучше среднего кодера при равном рабочем опыте. Из ученых получаются самые жуткие быдлокодеры. Поэтому лучше Питон, который будет карать даже за попытку сделать шаг не по уставу, чем Перл, с его возможностью сделать код абсолютно нечитаемым даже для автора.
Никто не говорил, что они будут лучше программировать. Как минимум это не их профиль, у них нет цели оптимизировать код, их цель — чтобы он выдал корректный результат с минимумом усилий. А интеллект у средних ученых повыше будет, чем у средних программистов. Сам сейчас в НИИ работаю.
интеллект у средних ученых повыше будет, чем у средних программистов
Это вы говорите, основываясь на результатах исследований или просто вам очень хочется, чтобы так было? Ведь вполне может быть, что поскольку вы работаете в НИИ, а зарплаты в российской науке несопоставимы с зарплатами в коммерческом IT, то вы просто выдумали себе компенсаторную легенду, согласно которой вы бедный, но умный.
Эмм, мне кажется вы сами себе выдумали легенду, что если в IT платят больше, то значит там люди умнее. Скажите еще, что фронтендер с 3-месячных курсов с з/п 50, умнее кандидата наук с зарплатой 30.
Я сисадмин, я работал и в IT-компаниях. Мое мнение основано на моем личном опыте общения и с программистами, и с учёными. И интеллектуальное сравнение чаще не в пользу первых, а вот «синдромом Бога» и чрезмерно завышенной самооценкой страдает каждый второй.
Мнение же окружающих, что программисты умнее исходит из того, что большинство из них пытается козырнуть какая он интеллектуальная элита, как угодно, но доказать, что он умнее окружающих. Среди ученых такого меньше.
Я сисадмин, я работал и в IT-компаниях. Мое мнение основано на моем личном опыте общения и с программистами, и с учёными. И интеллектуальное сравнение чаще не в пользу первых, а вот «синдромом Бога» и чрезмерно завышенной самооценкой страдает каждый второй.
Мнение же окружающих, что программисты умнее исходит из того, что большинство из них пытается козырнуть какая он интеллектуальная элита, как угодно, но доказать, что он умнее окружающих. Среди ученых такого меньше.
А я не делал никаких утверждений относительно ума людей других профессий. Это вы сказали, что дескать, интеллект у ученых повыше будет — вам и приводить доказательства.
О, можете дальше не продолжать. Это классика. Я собеседовал десятки бывших сисадминов, приходивших в качестве соискателя на должность разработчика.
Я сисадмин, я работал и в IT-компаниях
О, можете дальше не продолжать. Это классика. Я собеседовал десятки бывших сисадминов, приходивших в качестве соискателя на должность разработчика.
О, можете дальше не продолжать. Это классика. Я собеседовал десятки бывших сисадминов, приходивших в качестве соискателя на должность разработчика.
И о чем это говорит, кроме очевидного кризиса в профессии? Я также не говорил, что админы умнее программистов.
О том, что сисадмины регулярно недооценивают сложность работы программистов. Поэтому и идут на собеседование, где выдавливают из себя что-то типа «ну, я писал скрипты в баше и это… чуть-чуть правил CMS/биллинг», претендуя при этом как минимум на мида. Не понимая, что их знания — это даже не уровень джуниора. А в случае общения с представителями других профессий, у них, вероятно, не возникает иллюзии наличия собственных знаний. Отсюда и разные оценки.
А это плохо, когда сисадмин приходит на должность разработчика?
Странно но у меня сложилось противоположное впечатление, среди кандидатов и профессоров с которыми я общался была процентность высока «людей повернутых слегка», а ЧСВ у некоторых кандидатов просто зашкаливающее и обратно пропорционально возрасту. У программистов с этим намного проще, хотя видимо зависит от страны/города/предприятия…
Тоже, что и с фортраном, куча уже написанного кода, и батарейки в комплекте!
Да дело не в том, что учёному выучить ООП сложно. Дело в том, что учёному ООП, как правило, не нужно. Учёному, как правило, нужно быстренько написать небольшую программу для своих рассчётов, взять результат и, забив на программу (возможно, даже навсегда), углубиться в то, ради чего этот учёный, в конечном итоге, функционирует — написание статьи и пристраивание её в журналы/конференции. Возможно, он ещё раз-другой вернётся к этой программе, чтобы чего-нибудь модифицировать и высосать результатов ещё на пару статей, после чего, исчерпав тему, забросит её уже точно навсегда (и слава богу, ибо к тому времени ужасность его быдлокодерского поделия возрастёт настолько, что любым дополнительным «улучшением» он уже рискует пробить дыру в пространство отрицательного интеллекта, откуда вылезет Ктулху или ещё кто похуже).
Если же вдруг в его коде таки присутствует потенциальное reusability, то, чтобы превратить его в реальное, надо много думать, анализировать, проектировать, в итоге, скорее всего, написать библиотеку, и, вероятно, даже с ООП. Подобных примеров тоже полно, но, как правило, у нашего сферического учёного нет на это ни времени, ни желания, и платят ему не за это. И если он таки нахватался где-то баззвордов, кое-как выучил ООП и пытается применять — обычно выходит только хуже.
Если же вдруг в его коде таки присутствует потенциальное reusability, то, чтобы превратить его в реальное, надо много думать, анализировать, проектировать, в итоге, скорее всего, написать библиотеку, и, вероятно, даже с ООП. Подобных примеров тоже полно, но, как правило, у нашего сферического учёного нет на это ни времени, ни желания, и платят ему не за это. И если он таки нахватался где-то баззвордов, кое-как выучил ООП и пытается применять — обычно выходит только хуже.
У меня набор вопросов про фортран:
1. Как у него с безразмерными целыми?
2. Как у него зависит размер инта от битности процессора?
3. Как осуществляется управление библиотечными зависимостями и их установка?
4. На чём пишутся юнит-тесты для кода на фортране?
5. Как у него обстоят дела с юникодом?
1. Как у него с безразмерными целыми?
2. Как у него зависит размер инта от битности процессора?
3. Как осуществляется управление библиотечными зависимостями и их установка?
4. На чём пишутся юнит-тесты для кода на фортране?
5. Как у него обстоят дела с юникодом?
- Из коробки — никак.
- По умолчанию инт четырёхбайтный. Можно задать от INTEGER(1) до INTEGER(16) (иногда только 8).На экзотических архитектура не определено.
- Автоматического установщика как в новых средах нет.
- На чём угодно, нематиматическую часть нет ни малейшего смысла писать на фортране, а в новых стандартах (а по факту и в старых) фортрановские объектники линкуются с C/C++-ными. Так что вполне можно использовать GTest.
- Теоретически в новых стандартах есть всё для работы с юникодом. Практически — не видел ни единого случая, когда бы это использовалось. Область применения фортрана бесконечно далека от обработки текстов.
Вот три — это катастрофа. В смысле, тяжелейшее легаси. Если бы у них был аналог cargo, pip'a, bundler'а и т.д., то это бы сделало язык куда более переиспользуемым, а научные библиотеки — более доступными.
У Си тоже нет ничего подобного (сколько нибудь распространённого), это не мешает ему быть одним из популярнейших языков.
Да и с трудом представляю себе учёного "фортрано-боя" который с блеском в глазах качает ночами новые модные библиотеки, установить которые вручную он бы не смог (-:
У Си есть что-то подобное. Называется ldd. И всё остальное, сверху — dpkg/rpm, etc. Когда мне нужны готовые бинарники — ими управляет ldd, когда мне нужны хидеры — есть пакет libfoobar-dev, который ставит хидеры для бинарных пакетов libfoobar, который содержит файлы so'шек для ldd.
Система управления зависимостями в Си настолько встроена в современные операционные системы, что не все осознают её всеохватность.
Только в Си можно ожидать «сишную DLL/so» в системе. Никто в своём уме не будет ожидать в целевой системе «разделяемую библиотеку pascal» или «модуль go», а так же присутствующего менеджера для этих библиотек.
Система управления зависимостями в Си настолько встроена в современные операционные системы, что не все осознают её всеохватность.
Только в Си можно ожидать «сишную DLL/so» в системе. Никто в своём уме не будет ожидать в целевой системе «разделяемую библиотеку pascal» или «модуль go», а так же присутствующего менеджера для этих библиотек.
НЛО прилетело и опубликовало эту надпись здесь
У фортрана есть гигантский недостаток — код на нём не выполняется на GPU. В большинстве случаев лучше взять любую хорошую обёртку над OpenCL для любого любимого ЯП, хоть питона, и получить почти бесплатное распараллеливание. Так как математические и физические алгоритмы и в большинстве случаев формулируются терминах тензоров, матриц, и прочих линейноалгебраических структур и операций над ними, и эти операции хорошо параллелятся, более того gpu и были созданы специально чтобы выполнять на них линейно-алгебраические операции, то переписать это на класс-обёртку не должно составить труда, и получить более понятный и более параллельный и производительныйкод.
Так что fortran — это чистой воды ретроградство.
Так что fortran — это чистой воды ретроградство.
Там выше в комментариях написали кодовую фразу: «CUDA FORTRAN».
http://ccoe.msu.ru/ru/node/59
Чтож вы так? Совсем гуглить разучились?
Кроме CUDA для вычислений на GPU ещё можно использовать:
https://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
https://gcc.gnu.org/onlinedocs/gfortran/OpenACC.html
https://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
https://gcc.gnu.org/onlinedocs/gfortran/OpenACC.html
Как человек, который писал этот самый астрофизический код на фортране-77, могу сказать, что maintainability такого кода стремится к нулю — ведь ученые вдобавок еще и никогда не были профессиональными программистами, отчего код не только исторический, но и ужасающий своей начинкой. (Да, сейчас я уже благополучно отошел от астрофизики несколько лет как)
Если человек не в состоянии освоить достаточно простые и понятные вещи в ООП, то непонятно, какой из него ученый.
Если человек не в состоянии освоить достаточно простые и понятные вещи в ООП, то непонятно, какой из него ученый.
Это несколько э… холиварно.
Т.е. программирование — это инструмент.
Скажем композитор оценивается по красоте созданного произведения, а не потому как он сам хорошо играет на рояле.
Хотя да — бывает и то и то в одном флаконе.
Экспериментальная лаборатория. Приезжает парень из Германии. Я ему — Мартин — а ты можешь сам сделать термопару? Он: -Нет. Я: — как же так? Ты ж экспериментатор! Мартин: — А зачем? Есть техник.
У нас же каждый и швец, и жнец, и на дуде игрец. Хотя плюсы есть в каждом подходе.
— Свой код я предпочитаю настоящим программистом не показывать — берегу их хрупкую психику.
Т.е. программирование — это инструмент.
Скажем композитор оценивается по красоте созданного произведения, а не потому как он сам хорошо играет на рояле.
Хотя да — бывает и то и то в одном флаконе.
Экспериментальная лаборатория. Приезжает парень из Германии. Я ему — Мартин — а ты можешь сам сделать термопару? Он: -Нет. Я: — как же так? Ты ж экспериментатор! Мартин: — А зачем? Есть техник.
У нас же каждый и швец, и жнец, и на дуде игрец. Хотя плюсы есть в каждом подходе.
— Свой код я предпочитаю настоящим программистом не показывать — берегу их хрупкую психику.
Да дело не в том, что кому-то не понравится, дело в том, что код надо обслуживать, развивать и просто в нем не путаться, то есть в нем должно быть
- здравое разбиение на блоки, объекты
- невозможность перепутать типы и так далее
- возможность расширять под новые задачи без ломания задач предыдущих
- ясная логика построения.
- удобство совместной работы над кодом
то есть инструмент должен использоваться вместе с навыками эффектиыной работы, которая собственно и страдает, когда человек вместо использования кода должен неделями в нем просто разбираться(!) и когда рефакторинг опять-таки длится неделями и ломает предыдующую версию кода, отчего код начинает плодиться в копиях "для того", "для этого".
Физики всем тем, что вы перечислили, не занимаются, у них другая работа и другие цели.
Если нужен не разовый инструмент для оценки/расчета, то и пишут такие вещи программисты, у которых консультантами в предметной области являются те самые физики. Конечно, бывают исключения, но они лишь подтверждают правило: физика — физикам, программирование — программистам.
Если нужен не разовый инструмент для оценки/расчета, то и пишут такие вещи программисты, у которых консультантами в предметной области являются те самые физики. Конечно, бывают исключения, но они лишь подтверждают правило: физика — физикам, программирование — программистам.
Я не знаю о ком вы говорите, но я кандидат физматнаук, 15 лет в этой сфере, защищался в ИКИ РАН, бывал в ряде институтов Европы. Был знаком с большинством активных ученых в моей сфере, существующих на свете.
И никто, кроме самих ученых, им код не пишет.
Если вы кого-то конкретного знаете, кто может позволить себе нанять мальчиков-зайчиков (я знаю расценки консалтинга), то мне очень интересно будет эту кулстори узнать.
плюсанул бы ваш комментарий, но нету прав :)
Я плюсанул за Вас.
Точно, никто нам, ученым, код не пишет.
Наследуем от Учителей, обмениваемся с коллегами-учеными.
Вот так, чтоб я пришел к кому-либо из программистов и попросил что-то для меня написать — такого не помню.
Ну нельзя (физически) переписать, например, все «рецепты» на JS за время выполнения мастерской диссертации.
Да и нужно ли?..
Точно, никто нам, ученым, код не пишет.
Наследуем от Учителей, обмениваемся с коллегами-учеными.
Вот так, чтоб я пришел к кому-либо из программистов и попросил что-то для меня написать — такого не помню.
Ну нельзя (физически) переписать, например, все «рецепты» на JS за время выполнения мастерской диссертации.
Да и нужно ли?..
НЛО прилетело и опубликовало эту надпись здесь
Мм… Ума не приложу, зачем учёным ANSYS?
Я-то думал, что его наоборот — пишет команда учёных, исследователей и программистов для того, что бы облегчить жизнь простым инженерам.
НЛО прилетело и опубликовало эту надпись здесь
ЦАГИ научно исследовательский институт. В том числе решает обычные инженерные задачи. Что и написано по ссылке:
В работе представлены результаты численного моделирования обтекания одиночной лопасти несущего винта.… Полученные результаты сравниваются с экспериментальными данными и результатами моделирования… Показано удовлетворительное, а в некоторых случаях и хорошее согласование расчетных данных, полученных по разным методикам, с экспериментальными.
Ничего общего с фундаментальной наукой, никаких открытий не делается и не предполагается, рассматривается один из инструментов сокращения периода испытаний.
Да и написали ANSYS не ватага хипстеров-фронтендщиков решивших показать учёным как правильно расчехлять IDE.
И кстати… Не знаю как там Fluent, а ядро ANSYS SFX написано на чистейшем F95.
НЛО прилетело и опубликовало эту надпись здесь
Можно забомбить куда угодно, но если этой суперсреды не будет у того, кто должен подтвердить/расширить/использовать расчёты — чуда не произойдёт.
А что с ней будет чрез 50 лет?
НЛО прилетело и опубликовало эту надпись здесь
Ну наверное тем, что рассматривает более общие вещи, очень далёкие от непосредственного практического применения.
Я не писал кандидатских и не смогу объяснить за объект, предмет и методологию исследований, но на бытовом уровне всё просто:
- Когда учёный пишет программу для обсчёта взаимодействия π-мезонов с протонами, это фундаментальная наука.
- Когда я заряжаю ANSYS на расчёт (очень похожий на тот, что в статье) — я занимаюсь инженерным делом.
- Если я вдруг решу обобщить миллион расчётов ANSYS и сотню тысяч экспериментов, то это будет уже наука… Только в области статистики, а не аэродинамики.
Наукой занимаются те, кто пишут ANSYS и расчётные модели для него.
Инженерная задача — выполнение расчета.
Фундаментальная наука — создание идеи расчета (уравнения, приближения, типы условий, расчетная схема) и только после этого расчет.
Фундаментальная наука — создание идеи расчета (уравнения, приближения, типы условий, расчетная схема) и только после этого расчет.
Теоргруппа Стухлика в Опаве имеет «мальчика-зайчика», вся работа которого — писать код. Группа Пайро в Принстоне (часть бывшей группы Отта в Калтехе) — тоже.
Значит физики и не должны писать код, в штате обязательна пара профессиональных высококлассных программистов, свободно владеющих численными методами и мат.методами рабочей области. Или можно дойти до того, что профессор обязан уметь пользоваться всеми видами сварки, быть асом электроники, и точить на станках свое экспериментальное оборудование. Можно разве что потребовать умение работать в какой-нибудь мат.среде типа mathematica, для которой проф.программист пишет заказные модули расширения.
НЛО прилетело и опубликовало эту надпись здесь
Второй одинаково хорошо вгонит шурупы во все 3 доски, при этом он не сможет вогнать гвоздь.
Второй — лошара.
Помнится, был у меня такой опыт, с забиванием гвоздей отверткой.
Повторить такое по доброй воле, конечно, не возьмусь, но если надо, ...
Проблема аналогий в том, что они почти никогда не соответствуют реальности, а лишь иллюстрируют фантазии автора аналогии.
где то я эту булочку уже видел и не так давно…
Похоже это не заслуга Фортрана, а недоработка Си, в котором многих полезных вещей нет принципиально, потому что их переложили на библиотеки, нередко друг с другом не совместимые.
НЛО прилетело и опубликовало эту надпись здесь
Как-то странно читать «скорость программы на С».
Вот например, MATLAB раньше рекомендовал под Windows в качестве дефолтного С компилятора Microsoft Windows SDK 7.1, а в последних версиях рекомендует MinGW 4.9.2. И я полностью поддерживаю выбор MathWorks, потому что в моих приложениях разница в скорости скомпилированных mex-модулей была в 3 раза (!!!) в пользу MinGW. К слову, gcc под Linux давал очень близкие результаты.
А если при этом еще побаловаться ключами -march=native, то можно и еще процентов 20-30 выжать.
Так о какой такой сферической в вакууме «скорости программы на С» можно говорить и с чем-то сравнивать?
Вот например, MATLAB раньше рекомендовал под Windows в качестве дефолтного С компилятора Microsoft Windows SDK 7.1, а в последних версиях рекомендует MinGW 4.9.2. И я полностью поддерживаю выбор MathWorks, потому что в моих приложениях разница в скорости скомпилированных mex-модулей была в 3 раза (!!!) в пользу MinGW. К слову, gcc под Linux давал очень близкие результаты.
А если при этом еще побаловаться ключами -march=native, то можно и еще процентов 20-30 выжать.
Так о какой такой сферической в вакууме «скорости программы на С» можно говорить и с чем-то сравнивать?
Так фортран компилируется тем же самым gcc.
Потому что gfortran это всего лишь один из бекендов gcc, а Intel Fortran один из бекендов Intel Compilers.
Все опции кодогенерации, доступные для C/C++ доступны и для фортрана.
Суть в том, что математическая программа написанная в лоб на фортране с использованием стандартных средств, как правило будет быстрее программы написанной на С/С++ с использованием %вашей_любимой_библиотеки% даже после небольшой оптимизации.
После серьёзной оптимизации разница будет скорее в пользу С/С++.
Дешевле докупить железа, чем связываться с «программистом-оптимизатором». И причин несколько — 1) удобочитаемость кода; 2) поиск и исправление ошибок, особенно, если open-source; 3) понимание того, как работает и как должен работать код, а также результатов. Увы, но программист, скорее всего не поймет всю физику процессов моделирования, это я утверждаю со своей колокольни 10-летнего опыта DFT рассчетов.
Дешевле докупить железа, чем связываться с «программистом-оптимизатором».
Простите, не соглашусь с вами.
Полный цикл расчётной программы считается месяц (чистого времени, календарного — вдвое больше) на самом мощном суперкомпьютере на который хватило денег у организации.
Только переговоры о доступе к другому компьютеру (если деньги свалятся с неба) займут до полугода, а потом ещё очередь.
За какие деньги и какого железа вы предлагаете "докупить"? (-:
Не путайте веб-сервисы для редактирования картинок и расчёты для изделий стоимостью в десятки мегафранклинов.
Доброшу еще немного до кучи:
1. В OpenMP при редукции (reduction) только в Fortran можно использовать функции min и max, в C/C++ такой возможности не предусмотрено.
2. Некоторые на Fortran веб-серверы пишут: https://fortran.io/. Это почти как на ассемблере, только на Fortran. И наверное тоже «полезно и приятно».
3. Самому проверять не приходилось, но говорят, кроме мира x86 есть еще мир супер-компьютеров на основе альтернативных архитектур, для которых компиляторы Fortran выдают более производительный код по сравнению с компиляторами C. И никакой ifort вам под Cray код не сгенерирует.
4. Чего реально не хватает в Fortran, так это интринсиков. Я уже несколько раз встречал программы на Fortran, в которых критическая часть переписана на C с использованием интринсиков под Xeon Phi или AVX512. А виной этому, видимо, гарантированная (насколько это возможно) переносимость кода между разными платформами.
1. В OpenMP при редукции (reduction) только в Fortran можно использовать функции min и max, в C/C++ такой возможности не предусмотрено.
2. Некоторые на Fortran веб-серверы пишут: https://fortran.io/. Это почти как на ассемблере, только на Fortran. И наверное тоже «полезно и приятно».
3. Самому проверять не приходилось, но говорят, кроме мира x86 есть еще мир супер-компьютеров на основе альтернативных архитектур, для которых компиляторы Fortran выдают более производительный код по сравнению с компиляторами C. И никакой ifort вам под Cray код не сгенерирует.
4. Чего реально не хватает в Fortran, так это интринсиков. Я уже несколько раз встречал программы на Fortran, в которых критическая часть переписана на C с использованием интринсиков под Xeon Phi или AVX512. А виной этому, видимо, гарантированная (насколько это возможно) переносимость кода между разными платформами.
Года 4 назад у нас был курс вычислительной математики (очень интересный и полезный курс, хотя, к сожалению, многое уже забылось). В ходе курса нужно было написать программку, которая моделирует какой-то физический процесс. Чтобы мы не закопались, нам разрешили пользоваться библиотекой с реализацией типовых алгоритмов (например, для численного решения диффуров).
Библиотека была в 3 вариантах: Fortran 66 (оригинальный вариант), C и Pascal. Народ в группе решил не рисковать и взять привычную сишечку, а во мне взыграло любопытство — почему бы не попробовать новый язык, Fortran?
В целом, эксперимент удался. Язык оказался очень простым и удобным для моих задач, хотя и весьма своеобразным. Пока остальные подключали библиотеку к Visual Studio и возились с указателями, у меня уже всё работало. Писал я на современном Fortran 95, что вообще ни капли не мешало использовать старую библиотеку. Матричные операции — отличная штука, хотя не сказать, чтобы я активно ими пользовался. Больше всего проблем было с I/O — нужно было вывести матрицу в файл, и почему-то не получалось отключить перенос строки в операторе вывода.
С одной стороны, если бы был нормальный порт библиотеки на C++, с ООП и всеми делами, то может быть на плюсах было бы и удобнее. Но в случае математических библиотек в большинстве случаев порт — это просто адаптация под синтаксис другого языка. Так что даже если под C++ или другой язык будет подходящая библиотека, далеко не факт, что решить задачу на нем будет быстрее, чем на Fortran.
Библиотека была в 3 вариантах: Fortran 66 (оригинальный вариант), C и Pascal. Народ в группе решил не рисковать и взять привычную сишечку, а во мне взыграло любопытство — почему бы не попробовать новый язык, Fortran?
В целом, эксперимент удался. Язык оказался очень простым и удобным для моих задач, хотя и весьма своеобразным. Пока остальные подключали библиотеку к Visual Studio и возились с указателями, у меня уже всё работало. Писал я на современном Fortran 95, что вообще ни капли не мешало использовать старую библиотеку. Матричные операции — отличная штука, хотя не сказать, чтобы я активно ими пользовался. Больше всего проблем было с I/O — нужно было вывести матрицу в файл, и почему-то не получалось отключить перенос строки в операторе вывода.
С одной стороны, если бы был нормальный порт библиотеки на C++, с ООП и всеми делами, то может быть на плюсах было бы и удобнее. Но в случае математических библиотек в большинстве случаев порт — это просто адаптация под синтаксис другого языка. Так что даже если под C++ или другой язык будет подходящая библиотека, далеко не факт, что решить задачу на нем будет быстрее, чем на Fortran.
Очень интересная статья. Много узнал о Фортране.
Спасибо за статью автору!
Спасибо за статью автору!
Мне кажется, что многие просто не могут осознать, какое это болото Fortran.
Особенно, в режиме «fixed-form source», в котором длина строки должна быть не больше 72 символов, а символы дальше 72 позиции просто игнорируются.
Сейчас такое может присниться только в самом страшном сне.
Особенно, в режиме «fixed-form source», в котором длина строки должна быть не больше 72 символов, а символы дальше 72 позиции просто игнорируются.
Сейчас такое может присниться только в самом страшном сне.
Fixed-form был нужен для вполне конкретных целей — набивки на перфокарты, с чем прекрасно справлялся.
Использовать его для нового кода никто не заставляет.
Преобразовать его во Free-form можно питоновским скриптом на десяток строчек.
Меня бы больше волновали хаотично "сцепленые" циклы, Computed GOTO, и братские могилы данных в COMMON блоках (-:
Вот реальная библиотека: https://sourceforge.net/projects/ani2d/
Датирована 2014 годом, сделана с использованием fixed-form.
Интерфейс функций по современным меркам, мягко говоря, неудобный.
Авторы, конечно, молодцы, постарались сделать максимально удобно, но все равно это остается анахронизмом.
Датирована 2014 годом, сделана с использованием fixed-form.
Интерфейс функций по современным меркам, мягко говоря, неудобный.
Авторы, конечно, молодцы, постарались сделать максимально удобно, но все равно это остается анахронизмом.
Датирована 2014 годом, сделана с использованием fixed-form.
Но вас-то они не заставляют так писать? (-:
Стиль КМК связан с тем, что библиотека начала разрабатываться где-то в начале 90-х. Скажите ещё спасибо, что они используют инденты. Да и вообще код довольно читаемый.
Интерфейс функций по современным меркам, мягко говоря, неудобный.
Ну так создателям видимо довольно удобно. Если неудобно вам, то я не понимаю почему в репозитории нету фичереквеста?
Да какая разница на чем пару чисел между собой множить? Они же физики, а не кодеры. Тем более какие-нибудь известные алгоритмы уже есть на Фортране. Зачем переписывать это на другой язык, когда можно сделать ctrl+c, ctrl+v и не париться? Много ты, анон, переписал шифрование по ГОСТу на свой любимый бейсик?
В Северной Америке любое производство должно пройти природоохранную экспертизу.
Консалтинговые компании обязаны использовать утвержденный министерством код, который исторически был написан на фортране. Теперь этот код регулярно поправляется, но переводить на другой язык уже никто не будет.
Оболочки теперь пишутся на C++/C#/Delphi/Java
Консалтинговые компании обязаны использовать утвержденный министерством код, который исторически был написан на фортране. Теперь этот код регулярно поправляется, но переводить на другой язык уже никто не будет.
Оболочки теперь пишутся на C++/C#/Delphi/Java
В 1986 году в здательстве «Финансы и статистика» вышла книга Орлов В.Н. «Комплексирование программ в ОС ЕС».
Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.
Был бы здорово может и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.
Был бы здорово может и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
Потрясно!
А вот если FORTRAN приспособить для расчёта процессов в организме человека?
Сразу, целиком.
Вытянет?
А то всё как то по отдельности:
Пакеты прикладных программ по биомоделированию.
hpc.icc.ru/software/libraries.php
Systems Biology Markup Language (SBML) - формат представления, основанный на XML, для сообщения и хранения вычислительных моделей биологических процессов.
ru.knowledgr.com/02153233/SBML
KVAZAR» — открытый многопроцессорный программный комплекс молекулярного моделирования
nanokvazar.ru/kvazar
«ТРЕТЬЯ РЕВОЛЮЦИЯ В БИОМЕДИЦИНЕ»
vechnayamolodost.ru/articles/drugie-nauk...hizni/tretrevvbio4e/
Способ быстро предсказывать структуру белковых комплексов
www.nanonewsnet.ru/news/2016/uchenye-nas...belkovykh-kompleksov
Моделирование структур белков
kib.nsu.ru/?page_id=1488
сверхбыстрый метод моделирования белковых взаимодействий
university.innopolis.ru/news/cluspro/
Ученые смоделировали внутриклеточную среду на атомарном уровне
www.nanonewsnet.ru/news/2016/uchenye-smo...-na-atomarnom-urovne
Ученые работают над созданием первой трехмерной модели живой клетки
www.nanonewsnet.ru/news/2016/uchenye-rab...modeli-zhivoi-kletki
А вот если FORTRAN приспособить для расчёта процессов в организме человека?
Сразу, целиком.
Вытянет?
А то всё как то по отдельности:
Пакеты прикладных программ по биомоделированию.
hpc.icc.ru/software/libraries.php
Systems Biology Markup Language (SBML) - формат представления, основанный на XML, для сообщения и хранения вычислительных моделей биологических процессов.
ru.knowledgr.com/02153233/SBML
KVAZAR» — открытый многопроцессорный программный комплекс молекулярного моделирования
nanokvazar.ru/kvazar
«ТРЕТЬЯ РЕВОЛЮЦИЯ В БИОМЕДИЦИНЕ»
vechnayamolodost.ru/articles/drugie-nauk...hizni/tretrevvbio4e/
Способ быстро предсказывать структуру белковых комплексов
www.nanonewsnet.ru/news/2016/uchenye-nas...belkovykh-kompleksov
Моделирование структур белков
kib.nsu.ru/?page_id=1488
сверхбыстрый метод моделирования белковых взаимодействий
university.innopolis.ru/news/cluspro/
Ученые смоделировали внутриклеточную среду на атомарном уровне
www.nanonewsnet.ru/news/2016/uchenye-smo...-na-atomarnom-urovne
Ученые работают над созданием первой трехмерной модели живой клетки
www.nanonewsnet.ru/news/2016/uchenye-rab...modeli-zhivoi-kletki
Потомучто физики не программисты. У них другие задачи и другие темпы развития.
В 1986 году в здательстве «Финансы и статистика» вышла книга Орлов В.Н. «Комплексирование программ в ОС ЕС».
Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.
Был бы здорово можеть и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.
Был бы здорово можеть и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
Так и не понял, почему фортран сравнивают с C/C++, которые даже программеры выбирают только тогда, когда уже деваться некогда (или когда больше ничего не умеют). Там 90% времени будет уходить совсем не на описание алгоритмов и логики.
Есть же специальные научные среды: Matlab, Mathmatica и т.п., в которых не надо бедному физику постоянно думать в какую кучку какой указатель аллоцируется и прочую муру.
Никто в здравом уме, будучи знаком с C++ и Matlab не выбирает Matlab — все от него шарахаются. В С++ физику не нужно думать о кучках и указателях — вы имеете ввиду C. Писать софт в Математике, наверное, можно, но что-то я его особо не видал. Графики — да, матан — да. Но научный софт (не скрипты до 500 строк) пишут на C++ либо Python. Остальное используется от безысходности (legacy, отсутствие желания знакомится с python/c++ или наоборот желание попробовать «новый» для учёного язык типа Haskell, C# или Java). Исключения бывают, наверное, но всё же в подавляющем большинстве случаев выбор физика сегодня падает на C++/Python.
Странно, но в институте физики имени Л.В. Киренского почти все пользуются MatLab для моделирования, по крайней мере в области квантовой механики. Я сам пробовал сравнивать скорость работы кода на MatLab, C++ и Python/Scipy (который, внезапно, использует для вычислений LAPACK/BLAS написанный на Fortran). Код выкладывать не буду, ибо стыдно. Но смысл в том что неплохо зная Python я смог написать код который был в 3-4 раза медленнее чем на MatLab, для моделирования движения квантовой частицы в оптической решетке. Я пробовал заменить BLAS на ATLAS, но не сильно помогло. И даже попытавшись тоже самое написать на С++ я потратил около месяца в попытках оптимизировать скорость вычислений с помощью boost/uBLAS, и все равно не приблизился к скорости MatLab. Поэтому научиться писать код на С++ не трудно, а вот научится его писать быстрым уже не так просто, да и зачем если за тебя уже написали, пусть и на очень неудобном MatLab.
Потому от Matlab и отказываются повсеместно (вопреки сложившейся ранее традиции, когда у него не было конкурентов), что научится писать на Python код во всех отношениях лучше, чем Matlab-овский проще, чем изучить Matlab и им пользоваться. При этом возможности Python много шире и пользы от знания Python много больше. Если сравнение идёт по скорости, то Matlab надо сравнивать numpy или вообще numba, может быть. И я ниразу не видел что бы в этом сравнении Matlab одержал победу.
Обсуждение все больше скатывалось к идее «какой язык лучше»…
Да, микроскопом можно забивать гвозди, а молотком можно достать соринку из глаза. При большом желании =))
Лучше тот, который ты ЗНАЕШЬ! В совершенстве. Если ни одного — тот, который тебе легче будет выучить.
В сухом остатке — Фортрану фортраново, С — сишное, и т.д.
Само разнообразие и конкуренция языков — это чудесно.
Да, микроскопом можно забивать гвозди, а молотком можно достать соринку из глаза. При большом желании =))
Лучше тот, который ты ЗНАЕШЬ! В совершенстве. Если ни одного — тот, который тебе легче будет выучить.
В сухом остатке — Фортрану фортраново, С — сишное, и т.д.
Само разнообразие и конкуренция языков — это чудесно.
В C/C++ для этого требуется следующая запись:
int **array;
array = malloc(nrows * sizeof(double *));
for(i = 0; i < nrows; i++){
array[i] = malloc(ncolumns * sizeof(double));
}
Для освобождения массива в Fortran
deallocate(name_of_array)
В C/C++ для этого
for(i = 0; i < nrows; i++){
free(array[i]);
}
free(array);
1) Исправьте int на double.
2) Не в C/C++, а в C. В C++ для этого есть vector, а начиная с C++14 — dynarray (в частности, не нужно явное освобождение — в C++ автоматическое управление ресурсами). А в C99 есть variable length arrays, вообще идеально решающие эту задачу (правда, в C11 ставший опциональным, и с C++ они несовместимы).
3) Это явно не самый лучший способ выделить память под двумерный массив. Лучше выделить единым блоком — и выделение/освобождение проще, и работа будет эффективнее за счёт большей локальности данных и меньшей косвенности в обращении (правда, индексировать его будет сложнее).
Хотя не являющиеся программистами люди действительно так и будут писать.
Проблема в том, что const real отличается от простого real. Если функция, принимающая real, получит const real, она вернёт ошибку.
???
int f(double x);
int fc(const double x);
...
double y = 5;
const double yc = 9;
f(y); //OK
fc(y); //OK
f(yc); //OK
fc(yc); //OK
Может, имелась в виду какая-нибудь передача по указателю, для которого забыли написать const? (T* к const T* прекрасно преобразуется, если что.)
C – язык сравнительно примитивный, поэтому физики, избирающие себе C/C++, занимаются объектно-ориентированным программированием.
Это предложение сломало мне мозг. Имелось в виду, что физики, выбирающие C/C++, в силу примитивности C смотрят в сторону C++, а он объектно-ориентированный? И жалуются потом, что им сложно? И поэтому надо выбирать фортран?
Странная логика. Тем более что ООП — просто парадигма. Можно и на C++ писать в процедурном стиле (и не углубляться в изучение языковых средств поддержки ООП), а можно и на фортране мутить ООП, если очень надо.
Объекты – очень громоздкие структуры по сравнению со структурами данных, предпочитаемыми физиками: массивами.
В C++ классы могут быть неполиморфными, в силу чего их объекты физически будут представлять собой просто записи из полей (подобно derived type в том же самом фортране).
Объекты и массивы сравнивать бессмысленно, они разные задачи решают. Но даже если совсем забить на инкапсуляцию и вообще философию ООП, то «объекты» и «массивы» — это разные способы построения одних типов данных из других, они друг с другом не конкурируют. Массив — большое или неопределённое количество однородных элементов, объект — определённый набор разных по типу и/или смыслу элементов (лишь с учётом вышесказанного; на самом деле, разумеется, эта некая целостная сущность предметной области, а не агрегат для данных).
Если бы мы передавали его по ссылке, переданные данные не располагались бы в памяти подряд.
И как вы себе представляете в Си передачу по ссылке подмассива, элементы которого расположены неподряд?
Если первый индекс — индекс молекулы, то координаты одной молекулы будут располагаться подряд. В противном случае программисту на Си придётся вручную сформировать временный массив. Если только он явно не сделал одним из передаваемых параметров шаг (наряду с указателем на первый элемент и размером), специально для таких случаев.
Из моего опыта могу сказать следующее:
Чего не хватает в си++ из коробки — это нормальных многомерных массивов.
Что мешает в фортране — это отсутствие удобного ввода вывода и то что все переменные надо объявлять в начале функции.
Чего не хватает везде — это удобной интеграции с python/numpy array, потому что отдает голый указатель а не нормальный класс.
В остальном все работает одинаково имхо.
Буду рад увидеть в обсуждении конкретные примеры и опыт использования существующих инструментов.
Чего не хватает в си++ из коробки — это нормальных многомерных массивов.
Есть «почти» из коробки — Boost.MultiArray. Не могу сказать, является ли эта библиотека исчерпывающим решением проблемы, но когда мне подобное нужно было — хватило.
P.S. Для линейной алгебры (2D) лучше Eigen, Armadillo и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему физики всё ещё используют Fortran