Pull to refresh

Comments 431

Разные задачи, разные ситуации — в одном из проектов программка на C полтора месяца считала коэфициенты для алгоритма обработки данных с радара (на разогнанном i7 «x» процессоре с водяным охлаждением). Python в этом случае был бы вообще нерациональным выбором
Python+numpy с интелловским MKL вполне мог бы быть выбором, если в задаче много линейной алгебры
Если вы пишете код на 1/2 раза — почему-бы не объявить все «вариэйблс» «экстендедами», чтобы оно не падало? Ну и в статье всё-таки писать «переменные типа extended».
1) Если решается интегродиффур, то нужно вычислять значение из массива всех предыдущих, т.е. само выделение памяти уже грузанёт систему. (например — если расчитав изменение теплоёмкости, вы хотите сверить итоговую полученную теплоту с экспериментом и проверить правильность симмуляции — это к дальнейшему использованию этого же кода)
2) В данном конкретном случае предыдущие значения были не нужны, но extended не хватило бы. Нужны были именно операции вычислений над длинными числами.
Ситуации бывают совершенно разные, так что моя интуиция может оказаться в вашем случае и неправильной, но несколько лет работы над похожим сортом задач привели меня к выводу: если при решении физических задач численными методами не хватает двойной точности, значит, выбран неудачный метод.
С куска про C++ просто бомбануло.

а) «у вас нет гарантий что лог сохранится, в связи с падением ОС» Как выполнение пользовательской программы может привести к падению ОС? На Linux бывало, что память заканчивается и вываливаются какие-нибудь штуки, которые ошибочно считают частью ОС (например, какие-то куски GUI). Но даже такого я уже долго не встречал. Кстати в этом сценарии Python вешает систему с таким же успехом, причем из-за своей любви к отжиранию памяти это произойдет быстрее.

Что мешает вывести лог в файл, чтобы его даже после падения посмотреть? Почему вы считаете, что дебагер — это стартануть с первой инструкции и жать F(цифра) до того места когда упадет?

Про «кроличью нору»: сам видел, как люди включают тот же дебагер и начинают входить все глубже и глубже в какие-то дебри системных библиотек. Вопрос: зачем? Наличие ошибки в таких местах маловероятно. В первую очередь нужно понять, правильно ли вы вызвали функцию (нулевые указатели и т.п.). Всегда есть valgrind, memory-sanitizer для поиска проблемных мест с перезаписыванием чужой памяти и т.п.

По-поводу неожиданных падений. Неужто в python не встречали такой же штуки? Приходишь через час, а там уже все лежит и написано «nonetype is not iterable»? Имхо, если вы не умеете писать программы, которые работают, то 1) никакой язык вам не поможет 2) тупо сохраняйте результаты вычислений регулярно на диск, чтобы потом продолжить не с нуля.
Если у вас коєффициент расчитывается в цикле while до значения, которое вы расчитываете, то неправильный расчёт может нагрузить компьютер хоть и формально не бесконечным, но экспоненциально раздувающимся на каждой итерации циклом, который грузанёт систему, да так что придётся перезагружать. Пайтон в такой ситуации, конечно, грузанулся бы быстрее. Но он в неё в этом случае никак не попадает.
Код на винде, по крайней мере, может залезть в область памяти с кодом ОС, и крашнет её. Я помню, как мы с одноклассниками нечаяно 2 компа на уроках информатики, причём не на си писали.

Вывод в лог файл — у вас никогда не пропадали данные из документа, если он был открыт когда выдернули штепсель? Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце. Тогда будет 100% гарантия, и очень неудобная система записи.

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

Касательно падений Python — ни разу не падал на долгих вычислениях. Ошибался я, конечно, и на Python, кто не ошибается? Но вот разбирался быстрее.

Касательно кодов — все три были написаны не-программистами, а учёными. Которые знают как должны работать алгоритмы, и лексику этих трёх языков. Но интуитивный «наивный» код на пайтон почти всегда работает так, как ожидается. Аналогичный код на паскале далеко не всегда работает корректно. Ну а наивный код на си почти 100% даже не скомпилируется без каких-то специальных знаний.
Плюс к тому, на примере описаной задачи видно, что предсказать что где-то там на этапе исполнени возникнет в опасной близости расходимость решения диффура — нереально. И для языков вроде Пайтон это не проблема, а в си — для оптимального решения двух диффуров понадобится по разному выделять память, причём вам заранее неизвестно на что именно её понадобится больше. Вы видите число — а компьютер видит 32 или 64 и более битов. Пайтон немного сглаживает это недопонимание, а си — нет. В итоге вы просто переписали правильное уравнение, и вдруг выясняется, что когда а в диапазооне от 0.1 до 0.3 вам нужно выделять в два раза больше памяти на B и C, а затем обрезать результат их умножения, или деления в короткий тип… А затем выясняется что когда а > 0.3 вам надо делать это не с B и C, а с D и F. Тут знание языка не поможет, нужно ещё и знание ответов, до того как мы их ещё посчитали.
Так что думается мне, что ваши претензии к умению учёных писать программы не оправданы.
UFO landed and left these words here
Странный вы человек. Статья — взгляд человека из мира науки с его точкой зрения и объяснением его понимания причины популярности питона в науке. Для него ЯП — это один из инструментов, далеко не единственный. Эдакая помесь доски с формулами с жутко мощным калькулятором.

Я не говорю, что Си плох или еще что-то. Но по моим ощущениям у вас взгляд на вещи однобокий. Особенно эта фраза:
виноваты не разработчики, нет, виноваты языки программирования

Вы же понимаете, что автор не разработчик и не обязан им быть? Зачем ему осиливать кресты? Вы бы еще асм предложили и тыкали пальцем, что автор «ниасилил».

Вопрос: зачем ему вникать в тонкости разработки на крестах, когда он в разы быстрее напишет все свои формулы на питоне, получит результат и пойдет дальше? Был бы инструмент для почти любых задач более высокого уровня с низким порогом вхождения — использовали бы его.
Для него ЯП — это один из инструментов, далеко не единственный. Эдакая помесь доски с формулами с жутко мощным калькулятором.

Вот именно. Для учёных компьютер это такой большой калькулятор. И к программистам они нередко относятся как к операторам такого большого калькулятора. И качество кода там соответствующее. И мне страшно пользоваться результатами работы такого кода.

ИМХО. Как вы относитесь к учены, так и они к вам.
Качество кода не гарантирует верность вычислений при «дефектед бай дизайн». Так что я бы опасался пользоваться результатом работы именно такого кода.
Как вы относитесь к учены, так и они к вам.

Лично я к учёным отношусь с большим уважением.


Качество кода не гарантирует верность вычислений при «дефектед бай дизайн».

Зато плохое качество кода гарантирует наличие ошибок.

Для учёных компьютер это такой большой калькулятор.

И что характерно — учёные правы! :)
Передача «котиков в контактике» посредством этого самого калькулятора есть по сути его нецелевое использование.

Калькулятор это такое устройство, которое позволяет делать вычисления практически любому человеку. Обучение тут нужно минимальное, квалификация тоже не требуется. К компьютеру учёные нередко относятся так же. А между тем писать код надо уметь и квалификация тут очень важна.

Одно не исключает другого:
1. Писать код надо уметь.
2. Квалификация кодера важна.
3. Компьютер по своей сути — большой калькулятор.
4. Учёные относятся к нему соответственно п.3 и совершенно правы.
5. Следствие: учёные используют тот инструмент, который им более подходит исходя из пп.1-4. О чём и рассказывают.

А навязывать C/C++ в качестве инструмента для обработки числовых результатов опытов, да и вообще для разработки кода, связанного с математикой, это уж извините.
В далеком 1987 году я имел перед глазами пример, как шёл процесс на четырёх разных ЯП в части реализации как раз численных методов (ТОЭ).
Это были:
1. Turbo C 2.0
2. Turbo Pascal 3.0
3. Quick Basic 4.5
4. Fortran 80 (или 77).
Наименьшие трудозатраты были в реализации на «фортране», как и минимальный срок до получения результатов, затём был «паскаль», потом «бэйсик» и только потом C.
На вопрос к товарищу, писавшему на С — «а собственно зачем?», ответ был — на нём графика есть. Причём графика не для построения результатов расчёта, а для отрисовки модели ЛЭП.

Как показывает практика — прошло 30 лет, а ситуация с выбором инструмента, подходящего исходным условиям почти никак не поменялась :)
Одно не исключает другого:

Я писал, что калькулятор это устройство, которое не требует никакой квалификации от пользователя.


Вы пишите:


  1. Писать код надо уметь.
  2. Квалификация кодера важна.
  3. Компьютер по своей сути — большой калькулятор.

Как одно может не исключать другого?

Ну что же, попробуем внести ясность:
1. Компьютер, он же ЭВМ, это устройство предназначенное для выполнения вычислений. В первую очередь. Наличие в нём логических операций (введённых, как ни странно, тоже для управления расчетами) позволяет ему выполнять функции управляющего устройства или устройства коммуникации.
2. С точки зрения ученого естественнонаучника — это и есть большой калькулятор, который позволяет ему обсчитывать результаты, выполнять моделирование, рассчитывать прогнозные значения.
3. Соответственно учёному нужно, чтобы язык общения с этим калькулятором был максимально приближен или к его предметной области, или к используемому мат.аппарату. Что мы и видим в исходной статье.
4. Если инструмент отвечает требованиям п.3, то это означает, что наш абстрактный учёный с большой долей вероятности «умеет писать» нужный ему код. То есть обладает необходимой квалификацией.
5. А вот «писать код» на уровне системного программиста он не умеет. И его квалификация не позволяет этого делать.

На мой взгляд тут противоречий нет.

И если вы в своей практике используете компьютер для других целей и являетесь не прикладным разработчиком, то это не означает, что нет людей, использующих компьютер как «большой калькулятор», практически по его прямому предназначению :)

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


Питон из статьи не ближе к предметной области, чем С++. И к используемому мат аппарату тоже не ближе. Питон из статьи просто производит впечатление языка, который требует меньшей квалификации. Но это обманчивое впечатление — автор написал, что он написал код, который, в отличии от кода на C++ не упал. Почему — непонятно. Явно в коде есть какие-то проблемы, которые Питон маскирует, а С++ нет. Может это проблемы не критичные. А может очень критичные. Но на Питоне же там чего-то завелось, так что разбираться никому не охота.

Прямо, так прямо: калькулятор требует определённой квалификации пользователя.
Если сложить 2+2 — это одно, а вот провести цепочку расчётов без потери точности (не выписывая данные на бумагу), даже на инженерном калькуляторе — это ещё тот цирк. В своё время этому даже специально учили.

Кстати, не знаю как сейчас, но когда я учился в ВУЗе нас учили выполнению сложных инженерных (и математических) расчётов на разных инструментах, включая и ЭВМ (как тогда предпочитали называть компы :)). И с тех пор я не считаю ни калькулятор, ни даже счёты таким уж простым устройством :). Не говоря уж про логарифмическую линейку :)

Теперь про Питон и плюсы — питон требует не меньшей квалификации, а скорее обладает более низким порогом вхождения и главное для автора статьи — не требует усилий для обеспечения вычислений, не отвлекает от самой реализации алгоритма расчета. И это для него основное, в данном случае ему нет необходимости «лезть под капот». И пусть механизм работы с памятью для автора останется скрытым — для его задачи это не важно.
А на плюсах автору вместо написания алгоритма приходится уделять довольно много внимания тому что обеспечивает его расчет и в чём автор не разбирается и не должен в принципе разбираться.

Надеюсь, что моя позиция стала более понятной.
Просто всякому овощу своё место, и что не сделаешь на питоне, то можно сделать на плюсах. Обратное же скорее не верно :)
Статья — взгляд человека из мира науки с его точкой зрения и объяснением его понимания причины популярности питона в науке. Для него ЯП — это один из инструментов, далеко не единственный.

Для учёного и диффуры вместе с матаном и функаном тоже инструмент, если это не специализирующийся на этих областях математик. Но если этот учёный, скажем, применит какую-нибудь теорему Фубини, не проверив её условия, потому что ну а что, это же инструмент, и он слышал, что интегралы можно переставлять туда-сюда, а чего там конкретно, так он не математик, и потом ой, у меня тут чо-т интегралы какие-то странные, плохой, негодный матан, плохо зделоли тупо, то этого учёного, я думаю, немножко заклюют.
Все до безумия просто. Пример:
Если в расчетах потребуется найти пределы и по условиям можно применить правило Лопиталя, то оно будет применено. Нет нужды выбирать что бы применить из нескольких десятков возможных способов нахождения пределов. Тут прикол в том, что способ выбирается из условий.
В то же время, если нужно выполнить некоторые расчеты, то есть множество инструментов, которые позволяют это сделать. Зачастую инструмент выбирается исходя из трудозатрат на вычисления, в том числе (и зачастую на первом месте) человеческих. Я тут особо хочу подчеркнуть, что под инструментом для расчетов я совсем не обязательно имею в виду ЯП — это всего лишь одно из подмножеств инструментов.
Так ведь никто же не говорит о том, чтобы знать концепты из C++20, протоколы синхронизации кешей в процессоре и прочую подобную ерунду. Нужно знать свой инструмент на уровне, достаточном для его эффективного применения. Просто так получается, что правило Лопиталя и даже теорема Фубини сильно проще программирования с нуля.
если этот учёный, скажем, применит какую-нибудь теорему Фубини, не проверив её условия, то этого учёного, я думаю, немножко заклюют.


На старших курсах я теоретически обосновывал один экспериментально наблюдавшийся эффект. Вообще-то экспериментаторы его и сами обосновали, но у них были странные результаты, и это неудивительно: они записали два уравнения и разложили в ряд до третьей степени, только одно разлагали по x в предположении малого x, а второе — по 1/x в предположении малого 1/x. Их работа была опубликована в приличном журнале и часто цитировалась.

На защите курсовой я имел глупость проехаться по этой статье: обоснование там ошибочно, а мы, мол, подготовили хорошее обоснование. Но заклевали не их, а меня за апломб и панибратское отношение к научным зубрам. Конечно, комиссия признала неправильность подхода «зубров» и правильность — моего, поставив «отл» за работу и пожелав успехов в публикации, но за наглый доклад влепила мне тройку: негоже прямо называть математическую ошибку химиков-экспериментаторов ошибкой, нужно было критиковать попозитивнее и попочтительнее.
И это, на самом деле, очень грустная история, на мой взгляд.
А что в ней такого страшного? Члены комиссии на защите курсовой — это в первую очередь преподаватели, а не только оценщики. В идеале, задача преподавателя — научить добиваться успеха в своей области и всему что для этого требуется. Для того что бы добиться успеха нужны не только «технические» навыки непосредственно в области деятельности, но и коммуникативные, организационные — soft skills. Комиссия преподала студенту важный урок: мало сделать что-то хорошо, важно ещё грамотно это «продать» другим людям, не настроить людей против себя. Какой смысл в том чтобы прямолинейно говорить «экспериментаторы дураки — неправильно формулы записали»? Кому от этого лучше будет? Никому! Можно же конструктивно подойти, может даже пригласить их в соавторы, сказав: «давайте улучшенную версию вашей теории разработаем».

Неумение избегать профессиональных конфликтов — это тоже недостаток компетенции. Так что и с точки зрения оценки, комиссия права — не только «техническая» сторона содержания доклада имеет значение, но и «социальная», а также качество самой презентации (выступления) и прочее.
У меня сильно другой взгляд на вузовское обучение.

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

Неа, задача преподавателя — дать возможность получить знания. Прям подход старого Физтеха: не хочешь — не ходи на лекции, не ходи на семинары, никто этого не контролирует, сессия всё решит.

Поэтому если у вас нет выделенного предмета типа тех самых soft skills или хотя б какой-нибудь психологии, то вешать это на других преподов не очень оптимально.
Я далее буду использовать выделения, не воспринимайте это пожалуйста как «повышение голоса», это ради акцентов.
дать возможность
Я согласен, и это не противоречит тому, тому определению, что я привел. Когда я написал «научить», я имел ввиду «научить, если студент проявляет соотв. интерес». О принуждении речи не было.
Студент пришел защищать курсовую — значит он хочет получить обратную связь и что бы члены комиссии засвидетельствовали его навыки и дали им оценку.
Курсовая — это тренировочный мини диплом. Таким образом, комиссия, которая оценивает курсовую, делает комплексную оценку способности студента вести профессиональную деятельность. Оценивается не только способность применять навыки непосредственно связанные с курсом, но и оформление курсовой и способность решить все сопутствующие проблемы, необходимые для выполнения задачи курсовой. Социальные навыки входят в эти задачи. Тем более, что в данном случае проявились достаточно специфические «обычаи», характерные именно для академической среды. Их тоже необходимо знать и учитывать.
Ну, питон в научных задачах тоже надо уметь готовить. Лично видел, как объявление переменной внутри цикла приводило к выжиранию памяти на совершенно тривиальной задаче.
На самом деле, если уж сравнивать, особенно на задачах, подобных описываемой, то смотреть надо не на python vs C++, а на python vs fortran. И тут уже все не очевидно.
Фортран компилируется и работает на счетных задачах не медленнее (а зачастую — и быстрее), чем C++. При этом бережет границы массивов. Срезы и всякие хитрые выборки из массивов — из коробки. Передача параметров функциям — всегда по ссылке, но объяснить компилятору, что вот-эту-вот переменную трогать не надо и если я по глупости попытаюсь в неё написать — то это точно очепятка, надавай мне по рукам — это оно уже умеет. Горы кода — тот же lapack написан на фортране, например. Но няшных штук тит «pip install что-то-там» — я не видел (хотя, может уже и есть, не знаю).
Другое дело, что современные гики уже затянули, всё что могли, из фортрана в numpy и scipy, а знание python-а в современном мире куда более конвертируемо в ненаучные области, чем знание фортрана.
Да хоть эксель — тоже надо уметь готовить. Я ни разу не утверждал, что используя питон нужно вообще не глядя без мозгов что-то писать. Просто оказалось, что автору питон проще и быстрее приготовить. Вообще на питоне проще готовить, чем на крестах.
Для него ЯП — это один из инструментов, далеко не единственный.

Он взял молоток для забивания гвоздей (хорошо не микроскоп), но бьёт ручкой и плохой именно молоток, а другой молоток совершенно случайно взял правильно и у него получилось. Зачем осиливать молоток? Чтобы забивать гвозди, иначе не получится.

Когда я был маленький, знаете какой стороной я гвозди молотком забивал? Боком, ибо правильно у меня еще руки не могли нормально забивать — все время по пальцам норовил попасть.

Если человек вырос для владения молотком, то отлично! Молодец! Но если он еще не дорос до этого, то как его можно упрекать за то, что он не умеет пользоваться молотком правильно, если он все равно забил гвоздь и объяснил почему так делают многие?
Эта аналогия с молотком так разрослась, что я просто обязан ответить :)
дело в том что у молотка, шуруповёрта, и отбойного молотка почему-то наличествуют деревянные ручки, на которых надпись «ручка молотка». Только у молотка это действительно ручка, за которую надо браться, вид и название предмета соответствует его интуитивно понятному назначению. Но у шуруповёрта она торчит на месте кнопки включения, а у отбойного молотка это просто декоративный элемент. И даже если всё это написано в спецификациях к этим трём чудным моделям, это всё равно запутывает людей.
на которых надпись «ручка молотка»

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


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

Что на месте кнопки? У шуруповёрта и молотка это НЕ декоративный элемент, в обоих случаях ручка — это именно конструктивный элемент, предназначенный для удержания инструмента.


У меня складывается мнение что представление об окружающем мире некоторых айтишников несколько… мультипликационны.

Вы не поняли аналогию. Под молотком подразумевалось нечто более сложное, чем непосредственно молоток. Равно как и под остальными инструментами.
Из написанного этого никак не видно, а видно лишь фактические ошибки.
Секундочку. Но ведь Пайтон осилили. Значит проблема не в алгоритме была, а в том, какая логика выполнения. Если написать все вычисления от руки — результат будет как у пайтона, просто медленно. А проблемы более низкоуровневых языков, что вам приходится писать далеко не то же самое, что видите у себя в тетради. Их реализация того же синтаксического сахара менее полная, и в каких-то случаях даже самые элементарные абстракции вроде «число» или «строка» выявляют свою дырявую природу. Пайтон (а точнее, тот кто написал интерпретатор) реализовал абстракцию полнее, то есть лучше. Значит и язык — лучше, если все описанные на нём объекты ведут себя лучше. Си реализует массивы по примитивной формуле ссылка+индекс — в итоге это приводит к ошибкам в доступе к памяти. Делфи реализует переполнение для индексов массивов — и не вылетает, массивы Делфи лучше сишных. К массивам Пайтона можно применять кучу функций, которые мы можем сделать с обычным набором чисел в своих мыслях — его массивы ещё лучше. Точно так, как строки, числа, и многое другое. int — это целое число, но только от сих до сих. float — число не обязательно целое, но только пока вам не нужно очень маленькое, либо слишком большое, и есть ошибка представления, и потому оно творит мелкие гадости, которые в сумме могут наворотить больших дел. Если есть язык в котором эти две базовые абстракции менее дырявы — хотя бы могут запросить для себя больше памяти, или быть выведеными без конвертации — это уже большой плюс, и я написал о том, как этот плюс помог научному исследованию.
PS Абстракции пайтона тоже имеют свой предел, и свои дыры, но их меньше чем у си и паскаля.
А вот попробуйте GNU guile тут есть автоматическое повышение точности чисел Целые (5) > с плавающей точкой (real 5.0 ) > Дроби (ratio 10/2 ) > Точные (exact #e5.0) c длинной арифметикой и + Комплексные (5.0r + 0.0i).
Guile Manual: Numbers
И ещё: LUSH
Тоже умеет расширять численные типы и имеет кучу научных «батареек» (линейная алгебра, обработка сигналов и прочее). Эдакий фортран в скобочках.
Си реализует массивы по примитивной формуле ссылка+индекс — в итоге это приводит к ошибкам в доступе к памяти.

Далеко не это приводит к «ошибкам в доступе к памяти».
Положим вы ожидали, что на вход придёт изображение четырёхканальное, а оно пришло с тремя (без прозрачки). Аллокатор встроен куда-то глубоко в готовую функцию из библиотеки, которую вы используете. А вот работать с данными нужно вам конкретно здесь, в этой программе. Тогда вы начинаете перебирать пиксель за пикселем, и производить некие операции, скажем свёртки. При чём библиотека эта устроена так, что перевыделяет память на набор строк изображения, скажем на 3, либо на 5. В какой-то момент вы в коде продолжаете умножать до упора. А данных картинки под вашим свёрточным ядром уже нет. Какое-то время откомпиленный код перемножает случайные числа в неизвестных областях памяти, затем доходит до защищённой области и программа вываливается.
Да, безусловно, есть ошибка программиста, что не предусмотрен ввод изображений с разным количеством каналов. Но в любом языке где массив данных — это какая-никакая абстракция имитирующая реальный массив чисел, такого бы не могло случится — потому что реальные наборы чисел не включают ничего, что находится за их пределами, и ссылки на элементы должны вести себя подобно отдельному новосозданному типу — переполнятся, и всегда оставаться в нужных пределах. Даже если сам массив динамический — это никак не мешает делать поправки, пока выделяешь ему память на рантайме. Данные в таком языке всё равно были бы неправильные, что сказало бы программисту о проблеме. Но вылетать такая программа бы не стала. И никакой опасности для системы и других потоков вычислений представлять в принципе не способна. Почему-то для меня эррейтый элемент нуля не является чем-то осмысленным, а у С это будет точно такое же разыменование. Задумывались ли вы, как так то? Абстрактное понятие о масивах у человека есть, а реализации в C по сути нет. Не говоря уже о строках — это вообще для человека ясная вещь. Для С — ткой же дырявый массив слегка дырявых чаров. А если язык не стремится создавать более высокоуровневые абстракции, и с презрением отзывается о них как о синтаксическом сахаре, тогда чем он лучше кода ассемблера? (кроссплатформенность не в счёт, можно с таким же успехом написать транслятор одного ассемблера в другой, любой нестандартный (подобно тому как делают компилятор С отдельно для каждой платформы)).

К ошибкам в доступе к памяти приводит (чаще всего) неизолированность динамических массивов, которая является прямым следствием того, что массивы С — на самом деле не настоящие массивы данных — цельные объекты, а всего-лишь ссылки на 0-элемент, с прикрученным парсингом обращений в стиле массив[переменная-число]=>*(массив+переменная-число).
Какая разница, каким именно некорректным образом ведет себя программа, если она реализована неверно? Или вам для «научных» статей важен хоть какой-нибудь результат, даже если он неверно посчитан?
1) Если вы находитесь где-то в середине 2000-х годов и у вас там уже есть Windows XP, а Linux перевалил за 2.4, то вот вам радостная новость: ОС пристально следит за тем, чтобы процесс не уходил за пределы своей памяти. Вы НЕ сможете считать и, тем более, переписать произвольный блок данных. И ОС НЕ рухнет, если вдруг вы попытаетесь из своего приложения залезть в память драйвера. Даже под рутом этого добиться очень сложно.

2) Новость оттуда же: ваша ОС НЕ упадёт, если у неё закончилась память. Пошатнётся — безусловно, но что винда, что никсы уже давно пришли к тому, что пользователи приходят и уходят, а стабильность стабильно остаётся. Все системные процессы и драйвера имеют нужный запас памяти, а что будет с вашей difur.exe — это лично ваши проблемы.

3) Питон ЗАПРОСТО повалит комп из вашего сценария. Он сожрёт больше памяти, дольше будет мурыжить свои переменные, а потом с вашими же неверными параметрами вызовет сишный библиотечный метод. И перейдёт от стадии обеда в стадию танца. Питон ВЫГЛЯДИТ безопаснее, безусловно, на питоне гораздо быстрее пишутся одноразовые задачи — это тоже так, лично я порекомендую писать на питоне одноразовые маленькие задачи — скорее всего, да. Но это не серебряная пуля, и, тем более, не платиновый M60.

4) Тот поток мюслей, который вы написали, справедлив для С98-с-классами. Современные плюсы значительно отличаются по методологии написания. Банально, try{} catch(){} попробуйте использовать. std::bad_alloc, std::out_of_range, для любого более-менее продвинутого плюсовика ловить подобные исключения за собой — правила этикета.

5) Если вам написали, что вы должны передать в файл, скажем, png, а вы пихаете туда jpegrar, это, пардон пур мон франсе, разгильдяйство в терминальной стадии. «Ха-ха-ха, расстрелять.» И фразы типа "Я учёный, а не программист", "У меня нет времени писать проверки", "Я женщина, а не посудомойка" — это всё ещё более ужасные оскорбления самого себя. Не надо так.

6) На большинстве языков есть очень мощные фреймворки для решения математических — и не только — задач. Если начать с банального, оболочкой для вашей картинкомешалки можно взять тот же Qt, которому достаточно сообщить, в каком формате ты хочешь картинку — и уже он будет отвечать за её обработку. А ещё пропихнуть свой код обработки в QtConcurrent::mapped, Qt-шным эквивалентам питоновского map.
А если очередной отличник от науки вместо использования Blitz++ или gsl начинает своими кривенькими похотливыми ручками набирать те же алгоритмы самостоятельно, в процессе игнорируя любые обработки ошибок и пытаясь параллелить потоки без атомарок, это вопрос не к языку, а к отличнику.

7) Очень интересно, как легко будет портировать питоновый код на GPU? Не будет ли в Numpy лапшекода того же уровня, что и на сях? Не сожрёт ли Питон весь прирост производительности, который можно было бы получить от Xeon Phi?
Когда вы говорите «математические задачи», передо мной всплывает расчёт трёхмерных газовых объектов в миллиарде точек или построение карты загрязнённости города Кемерово на основании томов ПДВ всех производств в радиусе 150 км с шагом сетки в 20 метров. Сотни гигабайт входных данных, недели непрерывной работы расчётных блоков на очень мощном оборудовании. Прирост производительности на 1% — это 5-10 часов работы. И тут — питон. Приехали.
1)-2) после включения программы я не могу работать в системе. Виновата этом программа, но систему всё равно придётся перезагружать, ничего не отвечает, процесс съел всё. Вы знаете что это не падение системы. Для меня — разницы никакой. Машина не функционирует.
3) Не валит. Я использю одну и ту же библиотеку из пайтона и из С++.
4) Если вы продвинутый плюсовик — ок. Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи? Есть for, else, array — вещи, которіе узнаются во многих языках и понятны. try{} catch(){}, std::bad_alloc, std::out_of_range — это есть не везде. Более того, когда вы открываете чужой код, и видите все расчёты без этих вот штук — вы не знаете что их нужно дописать. Это нифига не очевидно. (на всякий случай напоминаю, что нерабочие коды на си и делфи написал не я — я только пытался помочь разобраться людям написавшим их, почему они не заработалали (а люди, которые их писали — знают совершенно точно, что языки программирования — это ада, фортран, паскаль и сиплюсплюс, они во многом ещё электронную почту и интернет не освоили, потому что впервые столкнулись с необходимостью моделирования. Обратились они ко мне, поскольку в отличие от них я изучал один язык в школе и в университете, и это в любом случае больший опыт чем у них. К си ни их, ни нас жизнь тогда не подготовила.))
5) иногда файл повреждён, и хотя имеет правильный формат, в нём неправильное число каналов. Я сталкивался с такими картинками. Если подтягиваете из интернета картинку с расширением png — ожидаете 4 канала. Но это не всегда так, в чём я и убедился, после написания той программы.
6) Надо было использовать формат той библиотеки, которая была нужна.
Если очередной отличник не переписывает алгоритм — программа работает в разы медленнее чем нужно, поскольку отличник оптимизирует код под конкретную задачу, а создатель библиотеки его задачи не знал.
7) Я расчитывал рост нанокристалов в 3д среде на миллиард частиц на пайтоне, было дело. И собирал данные шумовой загрязнённости в городе) Как ни странно оба названных вами примера очень близки к тем вещам которые делал я. Только одно я делал прямо пайтоном, а другое — в специализированном матпакете (без программируемых частей). У меня всё было достаточно быстро на мощном компе. Плюс, иногда программа работала где-то на фоне в течение дней, это да. Но прочитать все нужные статьи по вопросу и потом анализировать данные — это всё равно дольше. Так что время полного исследования не особо экономится.
Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи?

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

Человек говорит о том, что пайтон ближе к математическому языку (что достаточно перевести его под необходимый синтаксис и многое будет работать). И что вы подразумеваете под знать язык? Знание синтаксиса языка, не обеспечивает умение корректного его использования. Приводя пример выше, есть массив в си — это ссылка и сдвиг, и собственно если использовать все аккуратно, то не будет никаких проблем. Но массив для программиста — это одни кейсы использования, а массив для ученого — это другая история, для них все более абстрактно и кейсов сишных массивов недостаточно. Получается, что вместо того чтобы прочитать синтаксис языка и использовать его, человеку надо знать как его использовать, знать какие могут быть ошибки-крайние случаи, и указать для своего конкретного примера решения для тех случаев, которые актуальны в его конкретной задаче. И весь рассказ о том, что на пайтоне уже много сделано, абстракция настолько высока, что массу задач можно решить просто просмотрев синтаксис и написав "как на бумаге" почти один в один задачу интерпретатору. Другое дело, что:
-если хочешь быстрее — используй методы оптимизации;
-хочешь защиту от некорректного использования — делай кучу проверок и обработок входных данных и оборачивай все в исключения и тому подобное;
И во многих случаях, проще подождать выполнения задачи, чем сделать тоже самое в языках, которые ниже по уровню абстракции или не предназначены для выполнения данного класса задач.

В плюсах точно так же, нужно только выбрать подходящую библиотеку (но на Питоне тоже нужно ее найти и выбрать).

А ближе всего к математическому языку Хаскель
А ближе всего к математическому языку Хаскель

К маленькой доле математики — из прикладной математики так сходу и не сказать, к чему же он близок.
А что не так в нем с прикладной математикой?
Ну вы же утверждаете, что хаскель ближе всего к математическому языку — покажите, каким образом он ближе (питона например) к написанию численных методов решения уравнений, статистическому анализу данных, ...?
Правда интересно, писал всякую мелочь на хаскеле (даже пост на хабре :) ), но реальной пользы к сожалению не увидел.
Там же есть repa, accelerate, hmatrix и куча других ништяков вроде какого-нибудь ad. Статистический анализ данных — тут лучше R на самом деле, но если вам нужно запилить какого-нибудь Монте-Карло или что-то такое вероятностное, то был пакет с очень приятной монадой для рандома, забыл название, увы.

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

А за счёт определения своих операторов и уникодных литералов из коробки можно даже синтаксис особо не переводить, писать себе формулы, и всё. Да, у меня есть код, в котором уникодные лямбды и фи, оператор дельта для взятия дифференциала, и так далее.
Вот взял первый попавшийся пример со страницы hmatrix:
m ?? (All, Pos $ sortIndex (m!1))

Чем же это лучше (ближе к математической записи), чем
m[:, argsort(m[1])]

? И это всё оставляя за рамками вопрос, что все упомянутые библиотеки есть и для питона, а касательно
если вам нужно запилить какого-нибудь Монте-Карло или что-то такое вероятностное, то был пакет с очень приятной монадой для рандома

то в питоне (и в R, например) есть далеко не один пакет, причём достаточно зрелый.
Идейно мне хаскель очень понравился, но относительно большие проекты, особенно с этим самым переопределением всяких операторов, выглядят намного менее понятно «обычных» языков.
Чем же это лучше (ближе к математической записи)

Не знаю, потому что я не понимаю вторую запись.

Идейно мне хаскель очень понравился, но относительно большие проекты, особенно с этим самым переопределением всяких операторов, выглядят намного менее понятно «обычных» языков.

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

Ну «ближе к математическому языку» и «повсюду операторы $$, <|>, >|<, ?? т.п.» — это всё-таки две большие разницы.

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

Обычный математический язык:
aargmaxi bi
Питон:
a[argmax(b)]

странно, как можно понимать первую запись и не понимать вторую (если хоть немного знаком с любым программированием).
А вот
a ?? (Pos $ maxIndex b)

(написал примерно, не искал точное название функции) намного менее понятно.
Ну «ближе к математическому языку» и «повсюду операторы $$, <|>, >|<, ?? т.п.» — это всё-таки две большие разницы.

Увы, чтобы прямо совсем везде математический язык и юникодовые закорючки — это в Agda. В Idris, что характерно, от этого отказались, кстати.

странно, как можно понимать первую запись и не понимать вторую (если хоть немного знаком с любым программированием)

В исходной записи было ещё какое-то двоеточие, какая-то запятая, какой-то argsort. argmax понимаю, argsort — нет. Это такая перестановка индексов, что аргумент становится отсортированным? Или просто отсортированный набор чисел? Что такое m[1], m — матрица, что ли? Иначе зачем сортировать скаляр?

a ?? (Pos $ maxIndex b)

Ну было бы a ?? (Pos (argmax b)), было бы лучше? $ — оператор из стандартной библиотеки, позволяет избежать лишних скобочек, а ?? или [] — вопрос опыта от предыдущих языков программирования, а не от математики, скорее.
В исходной записи было ещё...

Если что, это две записи разных вещей :) Первая — взятый из примера к библиотеке, второй — простой argmax.

Ну было бы a ?? (Pos (argmax b)), было бы лучше? $ — оператор из стандартной библиотеки, позволяет избежать лишних скобочек, а ?? или [] — вопрос опыта от предыдущих языков программирования, а не от математики, скорее.

Нет, не было бы существенно лучше. Вы так легко отметаете «опыт от предыдущих языков», что достаточно странно — грубо говоря, все кто хоть немного программировал на чём-нибудь знают, что обращение к массиву идёт через [] (notable exception — матлаб, но круглые скобки оттуда всё равно к "??" не ближе). Ещё какой-то непонятный «Pos» стоит.

argmax понимаю, argsort — нет. Это такая перестановка индексов, что аргумент становится отсортированным?

Сёрьзно, не понимаете? А sortIndex так прям понятнее? Абсолютно простая запись — argmax возвращает аргумент (индекс), который при подстановке в массив даёт его максимальный элемент; argsort — возвращает аргумент(ы), при подстановке в массив даёт его элементы в отсортированном виде.

Что такое m[1], m — матрица, что ли? Иначе зачем сортировать скаляр?

Посмотрите на хаскель-код, там ведь это всё тоже есть — "(m!1)".
Если что, это две записи разных вещей :) Первая — взятый из примера к библиотеке, второй — простой argmax.

Поэтому я и говорю снова об исходной записи :)

Вы так легко отметаете «опыт от предыдущих языков», что достаточно странно — грубо говоря, все кто хоть немного программировал на чём-нибудь знают, что обращение к массиву идёт через []

Да, с этим трудно не согласиться.

Ещё какой-то непонятный «Pos» стоит.

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

Сёрьзно, не понимаете? А sortIndex так прям понятнее? Абсолютно простая запись — argmax возвращает аргумент (индекс), который при подстановке в массив даёт его максимальный элемент; argsort — возвращает аргумент(ы)

argmax я встречаю регулярно вот прям в формулах, argsort видел хорошо если раза два, и оба этих раза не отложились у меня в памяти. А зная иную наркоманистость разработчиков библиотек, лучше предполагать худшее.

Кстати, в этом профит статической типизации: по Ord a => [a] -> [a] и Ord a => [a] -> [Int] (а ещё лучше — Ord a => [a] -> [Idx] или вроде того) сразу очевидно, что каждая из них делает. Даже в документацию лезть не нужно, достаточно нажать :t в репле или магическое словосочетание в вашем редакторе.
Типобезопасность же. Негоже напрямую элементами массива индексироваться.

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

Кстати, в этом профит статической типизации: по Ord a => [a] -> [a] и Ord a => [a] -> [Int] (а ещё лучше — Ord a => [a] -> [Idx] или вроде того) сразу очевидно, что каждая из них делает. Даже в документацию лезть не нужно, достаточно нажать :t в репле или магическое словосочетание в вашем редакторе.

Хотя с общим посылом я согласен, но в чуть более сложных случаях всё-таки намного надёжнее смотреть название + docstring функции (который выводится по «func?» в репле или тоже по кнопке в редакторе). Да даже в этих простейших функциях я сходу вижу как минимум несколько вариантов: сортировка (2 штуки: по убыванию и возрастанию); или например в дополнение к сортировке может происходить выкидывание повторяющихся элементов.

Опять же, идейно это всё выглядит реально круто и полезно… Но если взять хотя бы небольшой кусок кода (например, ваш расчёт карандаша) и написать абсолютно такие же функции на питоне, а потом спросить обычного человека, который прошёл курс в универе по какому-нибудь C и всё — то я уверен, что ему хаскель будет намного менее понятен. Ну и удобств многих там нет, чего только стоят сразу бросающееся в глаза отсутствий named arguments и нормального форматирования (`show x ++ " " ++ show y` vs `f'{x} {y}'`).
Кстати, в математике спокойно бывает запись в духе aai — вот и индексация элементом массива.

Рефакторинг в математике, к счастью, выглядит совсем не так, как в программировании.

Хотя с общим посылом я согласен, но в чуть более сложных случаях всё-таки намного надёжнее смотреть название + docstring функции (который выводится по «func?» в репле или тоже по кнопке в редакторе).

В более новых языках это очень хорошо решено:
Prelude> :doc InBounds
Data type Prelude.List.InBounds : (k : Nat) -> (xs : List a) -> Type
    Satisfiable if k is a valid index into xs
    Arguments:
        k : Nat  -- the potential index
        
        xs : List a  -- the list into which k may be an index
        
Constructors:
    InFirst : InBounds 0 (x :: xs)
        Z is a valid index into any cons cell
        
    InLater : InBounds k xs -> InBounds (S k) (x :: xs)
        Valid indices can be extended

Но рекомендовать Idris для прикладных учёных — это перебор.

Ну и удобств многих там нет, чего только стоят сразу бросающееся в глаза отсутствий named arguments

data Args = Args { foo :: Int
                 , bar :: Double
                 , baz :: Float
                 }

instance Default Args where
    def = Args { foo = 0, bar = 0, baz = 0 }

doFoo :: Args -> Smth
doFoo Args { .. } = doSmthWith foo baz bar

callFoo = doFoo Args { baz = 0.3, foo = 10, bar = 3.14 }
callFooDef = doFoo $ def { foo = 20 }


и нормального форматирования (`show x ++ " " ++ show y` vs `f'{x} {y}'`)

Я был молод и не знал про Data.String.Interpolate (такие вещи в библиотеке вместо ядра языка — это офигительно изящно, как по мне). С ним оно просто [i|#{x} #{y}|].
Да уж, interpolate действительно выглядит красиво, особенно если учесть что это библиотека. Про named arguments — не очень понял, то есть это всегда было в хаскеле, получается?

Кстати, можете кинуть пару примеров реальных проектов на хаскеле (а то и ещё на чём-нибудь необычном типа idris), которые адекватно написаны, с использованием соответствующих фич? Такое ощущение что язык (или как минимум культура написания на нём) местами существенно поменялся с того времени, как я смотерл. В реальной работе конечно его использовать не получится — я такой код никому показать не смогу, чтобы его поняли — но просто потыкать что там да как интересно.

А про
Prelude> :doc InBounds

— там всё кроме Test if k is a valid index into xs несёт какую-то полезную информацию пользователю функции?
Да уж, interpolate действительно выглядит красиво, особенно если учесть что это библиотека.

Да, в этом прелесть квазиквотеров и вообще template haskell. Можно библиотекой сделать интерполяцию строк, raw string literals, вызов системных команд с аналогичной интерполяцией аргументов, компил-тайм-парсинг матриц и всё такое.

Про named arguments — не очень понял, то есть это всегда было в хаскеле, получается?

Ну, да (кроме того места, где Args { .. }, это расширение {-# LANGUAGE RecordWildCards #-}), но это немножко читерство. У вас теперь функция не n аргументов, а одного аргумента — рекорда с соответствующими полями. Её ни частично применять, ни flip'ать, ни что-то ещё не получится.

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

Кстати, можете кинуть пару примеров реальных проектов на хаскеле (а то и ещё на чём-нибудь необычном типа idris), которые адекватно написаны, с использованием соответствующих фич?

Раз мы тут за машинное обучение трём, вот, например. Но там хардкор :) Ещё в голову сразу, например, pandoc приходит, но там качество кода не везде образец для подражания — однобуквенные локальные переменные иногда смущают людей.

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

там всё кроме Test if k is a valid index into xs несёт какую-то полезную информацию пользователю функции?

Только это не функция, а тип данных, используемый для доказательства некоторых свойств других данных :)

А так — да, несёт. Видно, как строится это самое доказательство, и это можно напрямую использовать в моём коде.

Собственно, я сам только учу Idris, и вчера как раз примерно в это время столкнулся с соответствующим вопросом. Документация по деталям доказательства позволяет на него эффективно опираться.
Вы вручную разбираете PNG-картинку, или используете для этих целей какую-нибудь библиотеку? Если вручную, то должны были как минимум ознакомиться со спецификацией PNG, а там аж целых 5 возможных вариантов каналов есть (это не считая того, что бит на канал может быть не обязательно 8).
Если используете чужую библиотеку, которая этих нюансов не учитывает, то поздравляем, библиотеку писал рукожоп и проблем там может быть куда больше.
В любом случае, если вы «подтягиваете из интернета» — то должны относиться к этим данным с повышенной осторожностью.
Да, я использовал библиотеку человека, который такое не предусмотрел. Но он великолепно реализовал другие нужные мне вещи, потому я просто дописал кейс с другим числом каналов. Просто когда я запускал, то не ожидал таких вещей, и несколько раз программа таки завершилась с ошибкой, пока я разобрался в чём дело.
1-2) Помните, что пишется в уголовных кодексах в преамбуле?
Незнание законов государства не освобождает от ответственности.
То, что вы не знаете — и не хотите знать, что у вас происходит в ОС, крайне негативно характеризует вас как специалиста.

3) Давайте не будем спорить. Хотя бы в силу 1-2), просто примите 3) как данность.
4) Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи?
Объясните, откуда человек, впервые открывший код на Питоне, будет знать, что блоки определяются отступами и прерываются пустыми строками?

5) О том и речь, вы физически не можете написать реализацию для открытия и преобразования всех типов файлов в ваш формат. (Число каналов, в общем, произвольно, битность каналов не фиксирована, цветовых схем куда больше дюжины, многие форматы вообще защищены патентами) Не проще ли скачать библиотеку, которая, если смогла распознать файл, ГАРАНТИРУЕТ вывод сырых данных именно в нужном вам формате? Проще.

6) Только, Богом молю, не пишите свою ОС из-за того, что шиндовс виснит!
Кстати, а как этот пункт корреспондируется с тем, что вы же голосуете за Питон, в котором всё, что сложнее завершения приложения импортируется из готовых модулей?

7) Значит, при созвучности названных действий их реальная алгоритмическая сложность несколько отличается. У шума вообще достаточно простые формулы, ибо погрешности измерения в поле таковы, что дробные части можно просто отбрасывать за ненадобностью. У воздуха, всё-таки, и формулы позаковыристее, и число веществ под 500 уходит, и проходов до 10 штук для каждой из 16 сторон света.
Про рост кристаллов не скажу, но как-то у меня сомнения закрадываются. Такое чувство, что вы приукрасили число частиц на пару-тройку порядков. Иначе бы мы рассуждали не про питон и домашние пеки под виндой, а про выделенную никсовую ноду одного из суперкомпов о 64 cuda-ускорителях или таком же числе фишек, не говоря об mpi-архитектуре самого приложения. Признаюсь честно, расчёт газового облака я только видел у препода, и только в сокращённом виде, но даже так счётчик терабайт отработанных данных завораживал. (Даже Копатель бы работал на максималках с модами без тормозов.)

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

Мне кажется что люди, занимающиеся переписыванием библиотек си под пайтон — очень грамотные и разумные. В некоторых случаях они реализуют лучшую работу чем оригинал.
У воздуха, всё-таки, и формулы позаковыристее, и число веществ под 500 уходит, и проходов до 10 штук для каждой из 16 сторон света.

3 вещества, часть уже превращённая в кристал не просчитывается в рамках оптимизации, из-за диффузионного контроля. Проход один на итерацию, 8 связей по 3 координатам 3d сетки. Значит мой миллиард в среднем где-то в 40 раз меньше того, что упомянули вы. 40 раз тот мой код считался бы около 10 часов. На практике миллиард я запустил пару раз, чтобы показать справедливость эргодической гипотезы в рамках такой модели процесса, а дальше использовал 100млн ячеек, они за минуту просчитывались по сути, и можно было много модификаций попробовать. Для чего-то нужно большие куски, для чего-то хватает поменьше, такая жизнь.
А со звуком и правда простенько всё было.

А вообще, мораль статьи проста: если вы не являетесь специалистом в какой-либо сфере, и вам нужно срочно использовать нетривиальный инструмент из неё, не беритесь сами.

Проблема в том что где-то в жизни есть момент, когда человек вдруг захотел таким специалистом стать. Например, когда ему впервые понадобилось программировать для научной задачи. И тогда он смотрит на свой питон, потом на си, и снова на питон…
переписыванием библиотек си под пайтон
О чём речь?
Мне кажется что люди, занимающиеся переписыванием библиотек си под пайтон — очень грамотные и разумные.

Не знаю, как сторонние, но о стандартных библиотеках питона сложилось диаметрально противоположное мнение:
os.path.exists который робил через раз (по крайней мере на винде); довольно странный popen; thread, которые совершенно не thread (вот на кой их было так называть?).

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

В этом случае гораздо логичнее начать с гугла.

Ловить std::bad_alloc, std::out_of_range? Ой-ой-ой, что-то совсем плохо в мире С++.

4. Сильно bad_alloc поможет на линуксах с оверкоммитом?

6. Не надо этих blitz++ и тем более gsl, есть же относительно прекрасный Eigen и чуть менее распространённый, но чуть более прекрасный dlib.
Новость оттуда же: ваша ОС НЕ упадёт, если у неё закончилась память.

Память не сожрёт, но какой-нибудь цикл с тонной итераций по крайней мере XPшку запросто мёртво вешает. Не знаю, как с этим на Linux и более современных Windows: с такими ситуациями больше особо не сталкивался. Но почему при этом файл в лог не писать тоже не особо понятно.
Если запускать не от рута (администратора) и с пониженным приоритетом, то проблемы не должно быть. От используемого языка программирования это не зависит :)

У однажды повесил винду скриптом на питоне утечкой зомбяков.
Примерно так:


def frequently_called():
    popen = Popen()
    if some_condition:
        return
    popen.communicate()

К слову о безопасности питона — даже на нем система вешается запросто.
И я не был админом.

В дополнение к Antervis и iCpu я лишь могу добавить, что код на Си ведёт себя именно так, как и должен — если программа написана неверно, то не стоит ожидать от неё решения ваших проблем.

Ну и нельзя обойтись без самого детского аргумента о том, что на Си пишут оперрационные системы и ничего, как-то работают.

И я не спорю с тем, что возможно Си не подходит именно под вашу задачу. Но вы говорите о преимуществе одинх языков над другими в целом, а это не выдерживает никакой критики.
В аналоге Дельфи — Лазарус, есть ключи, которые включат контроль за переполнением в разных случаях, по умолчанию это не контролируется, что бы ускорить выполнение программы, что бы использовать их, надо прочесть документацию, а не быть программистом.
ключи
{$OVERFLOWCHECKS OFF}//Проверка переполнения целых чисел отключена
{$RANGECHECKS OFF}//проверка выхода за пределы массивов и диапазонов
{$S OFF}//Проверка на переполнение стека

В других языках, я подозреваю, всё — аналогично.
Зря подозреваете. В Си/С++ никакого контроля выхода за границы массивов нет. В C# и Java — есть и он неотключаемый.
В C# и Java — есть и он неотключаемый.

В C# он слабо контролируемый, т.к. он может отключаться JIT-ом.
Если совсем невмоготу, включаем unsafe и поинтерами тычем в элементы массива.


Про Java не знаю, но подозреваю что ситуация похожая.

Это не совсем массив… К тому же, если обращаться как раньше, через индексатор — проверки пропадут.

У вектора так же. И для ТС замедление расчета на 1% явно лучше, чем некорректные данные (судя по тому, что он даже к питону готов).

Си реализует массивы по примитивной формуле ссылка+индекс
Но мы ведь говорим о C++, где есть std::vector, если надо. В C тоже есть аналоги.
Делфи реализует переполнение для индексов массивов — и не вылетает
Вылетает, с исключением.
Если есть язык в котором эти две базовые абстракции менее дырявы — хотя бы могут запросить для себя больше памяти, или быть выведеными без конвертации — это уже большой плюс
Python/C++/Delphi этого не обеспечивают непосредственно. Это обеспечивается библиотеками для длинной арифметики, которые есть везде.
написал о том, как этот плюс помог научному исследованию.
Или о том, как набор принятых конвенций в Python и ваша конкретная реализация случайно привели к удачному для Вас результату. Вы не дали никаких обоснований для того, что бы утверждать что в следующий раз ситуация не поменяется и реализация на C++ заработает, а на Python провалится.
"… глазами учёного" и этим всё сказано. Вывод был предсказуем. Конечно это не языки виноваты, C++ и Pascal — языки для программистов, а не для учёных. Учёным лучше выбрать язык попроще и время на науку тратить, а не изучать ЯП по многу лет.
Ситуация меняется. А так то «Учёным лучше выбрать арифметику, а не изучать высшую метматику много лет».
Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце. Тогда будет 100% гарантия, и очень неудобная система записи.

У ОС есть механизмы гарантированной записи в файл, в правильной реализации логирования вы ничего не теряете. Для повышения производительности обычно используется файловый буфер на уровне ОС и именно он может потеряться при неожиданном завершении процесса. Но если вы вручную инициируете сброс буфера на диск, то почти гарантированно ничего не потеряете.

Случайно залезть в память системы можно как из Си так и из Delphi, но это скорее верно только для старых версий Windows. Разницы в этом моменте между Delphi и Cи нет.
Вот я таких тонкостей не знал. К сожалению, принципы функционирования ОС на таком уровне не изучаются физиками и химиками, и приходится выкручиваться.
Вот наглядный пример того разного взгляда: вы, как программист, знаете как решить проблему, сбросив на диск. Я, как учёный, этого не знал (кстати, не знаю и сейчас, хотя уже поработал немного программистом), вот и имел другое виденье — как нечто, чего не хочется повторять со своим компьютером в принципе, и в страхе за свои данные.
Я всегда думал, что ученные отличаются от людей тем, что любую вещь сначала изучают, потом проверяют изученное и только потом лезут с ней работать
То есть человек для численного решения условного дифура должен разобраться в устройстве ОС, серьёзно? Почему ж не в устройстве процессора и как он получен из песка?
UFO landed and left these words here
К сожалению, принципы функционирования ОС на таком уровне не изучаются физиками и химиками, и приходится выкручиваться.

ваш ответ:
Я всегда думал, что ученные отличаются от людей тем, что любую вещь сначала изучают, потом проверяют изученное и только потом лезут с ней работать


Мне показалось, что отсюда и следует, что вы хотите всех учёных заставить изучать строение ОС.
А в вычматах-то хоть он должен разбираться?
Очевидно да, так как без этого скорее всего не получится написать нормальный метод решения. А вот без знания устройства ОС — легко.
Все даже проще — вывод в stderr буферизуется подстрочно. ЕМНИП, можно установить построчную буферизацию и для произвольного потока вывода.

И кстати в отладчике можно ставить условные брейкпойнты.
И кстати в отладчике можно ставить условные брейкпойнты.

И каким будет условие? if (somewhere in the nearest future there will occur an error)
*Это не сарказм, если что, я правда не понимаю как компилятор может предвидеть рантайм ошибку и заранее начать показывать мне несколько предыдущих действий пошагово с выводом значений. Мб есть какие-то аналогичные интерпретатору оболочки, которые так и делают?
В момент краша дебаггер останавливает выполнение и можно посмотреть стек вызова и конкретное место, где произошла ошибка, откуда вызвана эта функция и т.д.
Проще надо быть.
У вас цикл? Вы примерно представляет, сколько раз он выполняется вообще? Допустим, миллион. Ок, поставили брейкпойнт на первой команде цикла с условием остановиться через миллион проходов. Упс, рантайм ошибка. Перезагрузка (если все так плохо), заново запустили, поставили с условием остановиться через полмиллиона проходов. Оно думает-думает и остановилось. Ок, значит полмиллиона отрабатывает. Сказали — остановись еще через четверть миллиона проходов.
Таким макаром локализовали (хорошо, если точно, а если нет — так хоть примерно) количество проходов цикла, после которого возникает ошибка. Теперь останавливаемся заведомо до ошибки, но близко к ней и смотрим, что у нас происходит. Не залезли ли мы где-то в чужую память или может стек переполнен.
зачем? Номер итерации — одна из переменных, значение которой в момент краша можно просто глянуть в дебаггере.
Ну если так, то хорошо. Просто у меня сложилась несколько иная картина. Цикл while, и краш сносит не только программу, но вешает операционку.
Задачи нередко запускают на много часов, дней и даже недель. Запускаешь моделирование, через двадцать часов всё падает. Отлаживаешь и обнаруживаешь, что падает-то на двадцатом часу, но причины этого падения возникли раньше, на восемнадцатом.
Могло бы быть хуже. Запускаешь на несколько недель, ничего не падает, получаешь результат. Но можно ли ему доверять? Может быть, там на восемнадцатом часу случилось прописывание памяти, оно попортило все вычисления, но программа не упала, так как прописывание проехалось только по внутренней памяти процесса.
Я прочитал ваш комментарий, и это какой то феерический поток сознания гуманитария. Давайте попробуем разобраться.

Если у вас коєффициент расчитывается в цикле while до значения, которое вы расчитываете, то неправильный расчёт может нагрузить компьютер хоть и формально не бесконечным, но экспоненциально раздувающимся на каждой итерации циклом, который грузанёт систему, да так что придётся перезагружать.
Насколько я понял, у вас есть программа и из-за её работы вы не можете управлять компьютером? Тут проблема с самой программой, которая некоректно потребляет ресурсы системы, ну или учёные что-то наковыряли в балансировщике ядра.

Код на винде, по крайней мере, может залезть в область памяти с кодом ОС, и крашнет её.
Кхм, тоесть учёные наговнокодили так что программа лезет в системную память и даже что-то там переписывает, потом учёные запустили эту программу под рутом(админом) и виноват, конечно, ц++. Гуманетарненько.

Я помню, как мы с одноклассниками нечаяно 2 компа на уроках информатики, причём не на си писали.
Сразу видно будущих учёных.

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

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

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

Библиотека логирования, говорите? Обычно используется print :) И хорошо если только для информационного вывода, а то бывает что и основной результат вычислений выводится принтом.

Понятно, что это не отменяет простого перенаправления в файл в shell'е.
Насколько я понял, у вас есть программа и из-за её работы вы не можете управлять компьютером? Тут проблема с самой программой, которая некоректно потребляет ресурсы системы

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

imgs.xkcd.com/comics/the_difference.png
что-то про выделение памяти и какой питон крутой

Нет, про типизацию, и какой пайтон крутой. Я где-то в другом комментарии боле подробно расписал.

То есть, я правильно понял, если программа не вылетела и выдала какие-то данные, то эти данные признаются верными?.. А вы точно учёный?

Если у вас коєффициент расчитывается в цикле while до значения, которое вы расчитываете, то неправильный расчёт может нагрузить компьютер хоть и формально не бесконечным, но экспоненциально раздувающимся на каждой итерации циклом, который грузанёт систему, да так что придётся перезагружать.

Один поток не может нагрузить ядро процессора больше чем на 100%. О каком "экспоненциально раздувающимся на каждой итерации цикле" речь?


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

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

При работе с файлами независимо от языка существует команда flush, которая физически сохраняет данные на диск, достаточно вызывать после каждого write (работать будет медленнее, но для лога важнее надежность), как говорится «было бы желание».

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

Вот тоже, абзац про C++ удивил.
Я реально не представляю, что нужно сделать такого в коде, чтобы наглухо завалить современную ОС (мы же не говорим про Windows 98 и прочий олдскул — там такое легко делалось) из юзерспейса с ограниченными правами. Вот серьезно, расскажите, кто-нибудь :)
Да, можно, конечно, отожрать все ресурсы, вызвать активный сброс страниц в своп, полностью забить дисковое I/O, что в купе с каким-нибудь багом типа известного 12309 сделает систему практически неработоспособной… Но такое можно при желании или при совпадении обстоятельств устроить на любом языке программирования, разве что в плюсах по неопытности можно утечек памяти наделать, а на языке со сборкой мусора GC в большинстве случаев подберет все что навалилось.

То же самое с записью логов «чтоб узнать, где упало». Не обязательно sync'ать буфер при каждой записи, можно писать блоками, и тогда при падении мы будем знать уже примерно в каком именно месте что призошло, и при следущем прогоне в этом месте логгировать более часто и детально. А для крэшей самого процесса почти всегда есть возможность посмотреть стектрейс. Короче, какая-то мутная история.

Может, выложите код на всех трех языках куда-нибудь на гитхаб?
Ну с си в итоге так и не разобрались, по скольку времени пожалели на это. Не могу сказать в чём конкретно проблема была, но это явно связано с сошибкой в вычислениях на том этапе.
Но, как я уже писал в комментарии, в школе на 2-ух компах уронили WindowsXP двумя разными кодами на паскале (даже не си). Потом, конечно, таких ошибок уже не допускали, но такие вещи вполне себе компилируются, сегфолты делают.

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

Давно уж это было, могу только пайтоновский поискать, я его сам писал с нуля, значит должен быть в наличии где-то на старых дисках… Но я помню что первые версии все кодов отличались только синтаксисом. Т.е. просто циклы, в которых считались итерации, и в каждом блоке подряд операции. Ничего сверх-особого, никакого использования особенностей языка. Разве что в делфи визуальная часть была в родном борланде нарисовано от руки, а так всё то же самое.

Andrey2008, подозреваю заинтересовался бы кодом и с полпинка дал несколько мест, где написано не совсем то, что хотели :)

Думаю, там для начала -Wall -Wextra -pedantic бы хватило.
Ну, можно сделать какой-нибудь while(fork()) {}; например.

Но зачем вообще нужны форки в числомолотилке?

Знаете, а у меня больше всего бомбануло с комментариев, подобных вашим, а не со статьи. Ну вызвало у вас возмущение то, что автор не осилил кресты, а где причинно-следственная связь с посылом статьи и вашим негодованием?

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

Замечу, что при этом до сих пор никто не дал ответ зачем автору вникать во множество нюансов используя кресты, когда он может с меньшими усилиями и быстрее по времени выполнить задачу используя другой ЯП?
Не люблю JS, но почему не JS? У меня вообще складывается ощущение, что ему несколько параллельно что у него внутри там упало — он продолжит считать :)
Есть мнение, что в JS 0.3 + 0.1 != 0.4. И это только самый простой пример.
Дак и в питоне 0.1+0.2 != 0.3

Вы меня пугаете) я в нём расчеты делаю. Что за фигня с типами/точностью?

Просто особенность представления чисел с плавающей точкой — десятичные дроби точно не представимы, возникает погрешность. Числа с плавающей точкой нельзя сравнивать на равенство (почти) никогда.

Да это везде так, где идет работа с плавающей точкой. Числа с плавающей точкой нельзя проверять на равенство, нужно делать как то так: abs(a-b) > 0.001

Спасибо, учту. Хотя у меня таких коллизий не возникало, не было сравнений в структуре.
В 3.5 добавили `math.isclose(a,b)`, который как раз проверяет что-то типа «Значения настолько близки, что (при дефолтных kwargs) разница между ними где-то порядка погрешности float».
О, благодарю. Хотя не вижу преимуществ перед abs(a-b) > 0.001. math.isclose хуже читается в плане порога разницы.
Чушь. Разные операции дают разную погрешность, нельзя так просто выбрать некоторую константу и всегда сравнивать с ней — а math.isclose, похоже, именно это и делает…
Не уверен, но вроде нынче для ряда языков это почти что не актуально. Компили сами подменяют сравнение. Где-то слышал, что так, но не проверял. Хотя, стоит отметить, на проблемы со сравнением со времён VB6 не натыкался.
там всё постоянно неявно конфертируется в строки. Простой пример:
[1,2,11,5,6,7].sort() // вернет 1,11,2,5,6,7

Поэтому если у вас на каком-то этапе интеграл вернул «банан» — это норма.
Я щас сам немного запутался. Meklon вроде как про питон говорит, а вы о JS говорите…
Пожалуй, это первый момент, с которым сталкиваются люди при расчетах с использованием типа float. В комментариях уже объяснили куда копать.

Хотите меньше сюрпризов не вникая в особенности — используйте decimal. Но я бы рекомендовал вникнуть в особенности — использование decimal не избавляет от нюансов, а просто несколько сокращает их количество (там так же есть нюансы).
Может стоит выбрать инструмент изначально ориентированный на научные вычисления?
Julia, R ни чуть не менее устойчивы, но более эффективны и ближе к математике.
Я правильно понял, что вы использовали числа произвольной точности с плавающей точкой в питоне? Или обычный numpy?

Промахнулся с комметарием — это вопрос к автору поста, удалить не могу
Тогда реально непонятно, как это вы говорите о малой скорости extended-float'ов, но числа произвольной точности нормально подходят. Ну и произвольная точность в питоне явно не по-умолчанию, надо явно использовать соответствующий модуль, почти как и в других языках.
В данный момент пытаюсь плавно перейти на Джулию, кстати. Однако есть три минуса: требует больших в сравнении с пайтон навыков работы с консолью, требует больших навыков сборки из модулей, и требует оформления даже простых команд в виде функций (иначе медленнее пайтона в разы).
Про R я стал наслышан, когда поработал программистом, как ни странно. В научной среде про него я не слыхал, соответственно тогда ещё даже не знал о его существовании.

Julia медленнее Python в разы? Можете показать пример кода?

Почти любой код с глобальными переменными. Если написать код в Пайтоне весь в корне, не в функциях, и то же самое сделать в Джулии — то Джулия подтормаживает серьёзно. Наверное это компилируется код на каждом запуске, вместо того чтобы один раз при первом, как когда оформлено в виде функций. Короче, не знаю почему, но дико тупит интерпретатор, если не запаковать всё в функции.
У них свои недостатки.
У julia: отсутствие полноценного комьюнити (по сравнению с промышленными языками программирования) и инструментов разработки (я пользовалься juno, до современных IDE явно не дотягивает), система сборки хуже чем в пайтоне, а по сравнению с javaским стеком технологий вообще детский сад.
R специализированный язык, та же julia язык более общего назначения.
А зачем для численного эксперимента язык общего назначения?

Я вообще удивлён, что всякие матлабы не предложили. И что конкретно potan — ATS, например.
Ну пример скорее не про python, а про любой более-менее адекватный интерпретируемый язык. Тот же common lisp замечательно (пусть и не всегда быстро) работает с любыми числами и даже с обыкновенными дробями прямо из коробки.
Подозреваю, что из списка интерпретируемых языков python выбирается всё же за готовый набор библиотек.
И возможность писать код так, как хочется(привыкли на basic/fortran/pascal/C). List и Hakell требуют слегка повернуть мозг предварительно.
Улыбнуло, спасибо, интересное наблюдение)

Или Scilab/Matlab. Нравится Scilab 6.0 — быстр, вынослив и кормить не надо. А уж визуализировать графики в нём — не проблема.

У Фортрана порог вхождения намного ниже чем в C/С++, неплохая поддержка объектно-ориентированного программирования, встроенная поддержка параллельного выполнения (coarrays), практически отсутствует алиасинг и как следствие код хорошо оптимизируется компилятором. Но — это классический старый язык, без онлайн инфраструктуры модулей и библиотек (как Питон), т.е. графики, GUI и т.п. прикрутить не всегда тривиально. Для HPC, там где нет GUI и требуется высокая производительность — сложно найти более сбалансированный вариант чем Фортран. Да и самые большие модели (>миллиона loc) — глобальный климат — почти все на Фортране.
Matlab как язык ужасен, а по скорости такой же как R и питон
Matlab как питон — хорош для быстрого прототипирования, серьёзные расчёты считает неприемлемо долго.
Из своего опыта — в университете помогал с дипломом, задача из области теории потоков (математический аппарат пересекается с гидро- и термодинамикой).
Первая попытка — Matlab+Simulink, верная модель, преподаватель всё проверил и одобрил. Одна проблема — считает неприемлемо долго (на моём пк за сутки около 1%).
Вторая попытка — голый Matlab без Simulink, уже лучше, но всё равно долго.
Третья попытка — переписал весь код на C++, день-другой конечно с отладкой повозился и оптимизациями, получилось быстрее в несколько раз, но всё равно долго. Помогла аренда High-CPU instance на AWS — там всё просчиталось за ночь.
Давайте начнём с того, что вы сравнили «сложность дебага» трёх совершенно разных программ:
1. Неверной программы, которая никак не показывает прогресс выполнения.
2. Неверной программы, которая чертит график в процессе выполнения. Т.е. есть прогресс, есть точка выполнения, есть номер итерации
3. Верную программу.
И сделали вывод — проще всего устранить ошибку в провильно работающей программе.

Во-вторых давайте про С++:
1. Определитесь с терминами: у вас падает ОС или приложение (и есть .core файл для linux)? Предположу, что второе.

2. Просто поймать в отладчике момент прихода сигнала от ОС — что в этом сложного (да возможно надо предварительно скомпилироваться с отладочной информацией).

3. У вас отдельным пунктом выделена ЗАДАЧА сохранить счётчик итерации в переменной — извините если это отдельная задача, то наверное действительно не стоит заниматься дебагом кода на С++.
Знаете, интересно что все программы были одинаковыми. Функции объявлены по разному, но делают с входными данными тоже самое, и выводят те же величины. Основная функция (процедура в делфи) делает одно и то же.
Когда человек пишет программу — она может с первого раза не заработать как он ожидает. Тогда он ищет где ошибки, и как правило процесс разработки начинается с неисправной программы (неверной). Бывают блокеры, бывают мелкие баги. Это не значит что программа плоха, это значит, что её дорабатывают. Поэтому мне не нравится называть программу, которая не выполняет ожидаемое, неверной.
Программа на С++ могла бы тоже вывести график, но вместо этого всё ломала. Она бы не вывела значений после критической точки, а делфи начал выводить неправильные — это само по себе полезная информация, да ещё и время на перезагрузку не тратится. Ну а Пайтон заработал не по вине разработчика — я не написал там ничего, чего не было в кодах на си и паскале. Я написал ровно то же — не импортировал никаких протекторов, не ковырялся в параметрах запуска, не лез в консоли, не писал проверок и тестов.

пункты 1-2, как мне кажется, не относятся ко всем трём языкам. А 3 — это не Задача, это этап, который должен был быть сделан, пусть это и две строчки кода.
И здесь речь скорее не о дебаге, а о полной разработке, т.к. в последнем случае дебага нет. Вы сначала описали, условно говоря, бизнес-логику вашей программы, сами выражения и в каком порядке и сколько раз их расчитывать — это занимает примерно одно и то же время на всех языках. После этого ваш код на Python — уже работает, на Delphi — надо немного доработать, на С++ — надо некоторое значительное время бороться с вылазящими из под половицы драконами.
Если «происходит какая-то очень нехорошая ошибка каким-то непонятным образом связанна с памятью» и эта ошибка, например, segmentation fault, то в линуксе следует заранее включить генерацию core dump с помощью ulimit (ulimit -c unlimited) и запускать дебаггер с файлом core.

Далее смотреть backtrace, что позволит узнать, что же произошло в программе с точностью до строчки кода, в которой произошла ошибка.
«Python… глазами учёного» = Волшебство интерпретатора помогает доброму питону увидеть, сколько памяти требует моё число, ...

За 6 лет то доктора получили? На защите о IEEE 754 упомянули?
Для ученого (* учёный == физик, химик, биолог, статистик и многие другие) этот ваш компьютер — просто очень мощный калькулятор. И учёный ищет, как быстрее посчитать, а не как написать код правильно, у него эти расчёты одноразовые (что указано в статье).
Компьютер для нормального современного ученого это ИНСТРУМЕНТ. По-моему для облегчения собственной жизни и увеличения производительности труда инструментом нужно уметь пользоваться.

Выглядит так, будто дали лопату, но не сказали какой стороной копать.

Никто не говорит, что вы должны написать клиент-серверное приложение с мобильным интерфейсом. Но вывод в файл или отрисовку уже по итогам рассчёта, а не в процессе…

Расчеты одноразовые? Да.
Единичные? Нет!
Так может научиться пользоваться?
Неумение учёных переводить задачу на язык машины печально, конечно же. Но, как консультант 1С я привык к тому, что люди впадают в прострацию, при перемене положений кнопок на панели инструментов. А Вы тут требуете программирования.
Мы, программисты, заточили свои мозги на программирование, и понимаем, что вместо нас никто задачу не решит. Другие люди не понимают.
Интересная вещь — всё, чего когда либо на моей памяти касались (из области программирования) на защитах физиков, это «в чём сделана такая визуализация?» — и то, только в случае если визуализация красивая, и кто-то из комиссии тоже такой график поверхности себе захотел.

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

Конечно была масса проверок
а) после расчёта данные дали правильный спектр значений состояний при комнатной температуре
б) после расчёта конечную точку подали на вход и расчитали в обратную сторону обратный процесс, он вывел систему в исходное состояние на нужном этапе
в) момент фазового перехода (экстремум графика) сошёлся с внешней к модели теорией
т.е. проверка по характеристикам спектра, +точка верификации в экстремуме, и по сходимости к исходному состоянию. Если говорить о теории в целом — то с тех пор прошло 6 лет, и за это время численное моделирование успели повторить в независимой команде с идентичным основным графиком, а также сама модель расширилась и опубликованы новые работы подтверждающие наличие ещё одного фазового перехода (который я открыл в тот раз, анализируя данные из Пайтона, то есть это также подтверждает их правильность)
Можно было, конечно, заняться точным расчётом сходимости, когда и функция, и её производная уже известны, но это не обязательно, так как расходимость обычно сразу либо видна на глаз из-за переполнения, либо (реже) неустойчиво уводит в сторону медленно, но верно, а в таком случае невозможно вернуться из тех точек к исходному состоянию, на то она и расходимость.
На мой взгляд, Python в научной среде любят вот за это: github.com/cranmer/ligo-binder/blob/master/GW150914_tutorial.ipynb.

Это пример обработки данных с LIGO (Laser Interferometer Gravitational-Wave Observatory — лазерно-интерферометрическая гравитационно-волновая обсерватория, экспериментальное обнаружение гравитационных волн космического происхождения).
А самые наблюдательные ученые еще и заметят как удобно использовать гитхаб
R и Julia в плане подготовке публикаций не хуже будут.
Все-таки описанные ваши проблемы не из-за специфичности задач, а из-за самой сути языков. Разработка на языках низкого уровня всегда дороже обходится по времени, и именно из-за того, что на них сложней отлаживать (и больше).
Сам пишу на C/C++ (в основном на C) и на Python для решения задач на графах. И скажу, что комбинация C и Python очень может помочь. Вдруг не слышали, но у Python есть стандартный модуль ctypes, который позволяет импортировать C-функции из библиотек. Может пригодится.
Еще вы в комментариях писал, что мол из-за программы падает ОС, но это ведь невозможно. Вы не можете вылезти в память ядра из-за того, что есть MMU. И никакая ОС не позволит вам своей программой все поломать (по крайней мере не должна). Но даже если из-за вашей программы вам приходится перезагружаться, то логировать нужно в файлы (как уже писали). Как по вашему разработчики ядер отлаживают все? Содержимое файла никуда не пропадет. Максимум не запишутся последние 4096 байт (это я на вскидку — точно, конечно, не знаю).
Я всё-таки выразился не совсем корректно. Имелась ввиду необходимость перезагрузки. Про запись логов мне уже сказали, спасибо, теперь я буду это знать.
Ещё один момент, если решите вернуться на C/C++: в циклах с ожидаемо конским количеством итераций ставьте sleep(0).
В Linux sleep(0) может не сработать, но для такого же есть sched_yield() и std::this_thread::yield().
Это лучший способ убить производительность и растянуть расчеты в десяток раз. Лучше пониженный приоритет себе поставить.
Выше уже написали про неумение пользоваться плюсовым дебагером и не буду повторяться. Главное делать правильный вывод из этой статьи. Многие комментаторы восприняли тезис «С++ это очень плохо, питон хорошо», а на самом деле выводом должно быть: «Порог вхождения в программирование на питоне намного ниже, поэтому для непрофессионального программиста он лучше, чем С++». С++, как и Delphi, является отличным языком в руках того, кто очень хорошо его знает и умеет пользоваться инструментарием. Плюсы карают тех, кто подходит к ним как дилетант. Питон поощряет дилетантов, но платить за это приходится скоростью и областью применения.
И просто от себя советую автору и всем учёным посмотреть в сторону D. Он быстр, как С++, но гораздо добрее к новичкам. Слышал много положительных отзывов от переехавших на D c питона.
Спасибо. Сам я уже с тех пор написал много всякого на С# и C++ (даже до С один раз дело доходило...), но моим коллегам пригодится. Проблема в том что кроме вашего совета тут в комментариях их уже очень много. И куда смотреть неясно — D, FSharp, scheme, common lisp, Fortran, Julia, R, Guile и Lush.
Что тут выбрать из букета? Осваивать все эти вещи и изучать что где применяется? Слишком много их всё-таки. Люди выбирают в итоге то, что на слуху. Вот я могу сказать как обстоят дела в науке. Люди в возрасте до 32 лет чаще всего используют пайтон. А наслышаны про
1) Пайтон 2) Фортран 3) Джулия, а также про 4) Паскаль 5) Си, но последние 2 не используют.
Среди старшего поколения чаще пишут на Паскале, и только в последнее время начали перенимать из-за бугра Фортран. Они слышали про Пайтон и Си ещё, но предпочитают использовать то, по чему на полке лежит учебник советских времён, т.е. дед Паскаль.

Многое просто решается в Математика/Матлаб/аналогичный пакет. Для программ используют один инструмент, обычно тот, которому первому научили. Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел. Даже те кто работает/работал программистом, хоть и знают некоторые альтернативы, всё равно придерживаются максимально простых решений, когда занимаются наукой.
Хаскель выбирайте, конечно же. Там типизация огого.
Что тут выбрать из букета?

А для этого нужны профессиональные программисты в штате. У совсем больших лабораторий и объединений есть профессиональные программисты. Тот же CERN публикует очень качественные библиотеки. С моей колокольни выбор выглядит так:
Нужно перемолоть кучу данных с максимальной скоростью? — C, C++, D.
Нужно посчитать статистику и работать с табличными данными? — R, Julia.
Нужна символьная арифметика с выводами — Matlab.
Исследуете теорию языков программирования — Haskel.
Не хочется запариваться со всем этим — Python. Если вдруг не хватит производительности зовём суровых сишников, они вынесут нагруженные функции в натив. Многие базовые уже вынесли, поэтому проблемы скорости возникают всё реже и реже.
Не совсем так:
Нужно перемолоть кучу данных с максимальной скоростью? — Fortran, D, C++, C.

Фортран появился в древние годы, и за время существования заматерел, большинство вычислений там сильно оптимизированы (да и язык попроще).
Что тут выбрать из букета?

Видится именно гуглёжка и проба. Изначально стоит о них почитать, глянуть, что в них в принципе есть и что он из себя представляет (а то можно и какие-нибудь таблицы сравнения найти). После этого скорее всего выйдет какое-то небольшое количество языков, которое стоит пробовать в деле. В целом, думаю любой язык можно освоить на базовом уровне и понять, что в нём есть где-то за неделю (а то и меньше). Кстати, не исключено, что окажется так, что язык A удобен для задачи вида X, а язык B для задач вида Y. Почему бы этим не воспользоваться?

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

Части кода можно выносить в библиотеки динамической компоновки и подключать к тем языкам, которые их поддерживают. По факту, такие библиотеки часто могут создавать компилируемые языки (но не все).
Вспомилась фраза: Программист на Фортране будет писать на Фортране на любом языке программирования.
Ну в принципе можно подставить название почти любого языка
Вот даа…
Мне школьный бейсик сознание сильно покорёжил, потом долго писал неструктурированный лапшекод на структурном Паскале =)

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

Python:
Нажал ctrl-s, палец съехал и добавил «d» к курсору. Вычисления идут, идут себе полчаса и потом — Бац! Нет такой переменной «var_named». В этом большая проблема питона — он может проигнорировать опечатки, или какие-то случайные ошибки, причём даже IDE не всегда их заметит.
В такой ситуации можно подвинуть палец к BS, удалить лишний символ, а потом с помощью комбинации Shift+Enter продолжить вычисления (проверено — в Anaconda/Spyder работает).
Так что не такая уж это и проблема.
Если вычисления идут полчаса и потом падают — скорее всего, некая подзадача выполнилась (раз за полчаса не было обращения к этой строке, значит выполнялся другой блок программы), имеются её результаты, и дело перешло к следующей. Для таких случаев куча решений — можно например просто писать и запускать такой одноразовый код в notebook (или просто интерактивном интерпретаторе, на выбор). Тогда результаты выполнившегося блока никуда не пропадут, даже если явно их не сохранять.

Вот с тех пор я и начал почти на каждый чих сохранять состояние. Проблема в том, что та же джава свалилась бы с ошибкой компиляции.

Но это ведь следствие динамической природы и интерпретируемости питона. С/С++/Pascal/etc тоже бы свалились на этапе компиляции. Нужно просто принять это как данность и использовать для решения задачи тот инструмент, который для этого больше подходит. Например, в моём научном коллективе долгие расчёты течений полимеров реализуются программой на C++, а обработка и анализ результатов на Python.
Коллеги, имейте уважение. Перед нами ПОЛЬЗОВАТЕЛЬ. И он то точно знает, что ему удобнее, не учите его писать программы, ему надо математику вперед двигать :-) А автору я бы рекомендовал посмотреть на FSharp.
Всё смешали. С и С++ — разные языки. С помощью RAII всегда можно было нивелировать проблемы с доступом к памяти и ее высвобождением, а развитие языка, выраженное в стандартной библиотеке, позволяет даже не напрягаться по этому поводу — всё уже сделано за вас. Уже слишком просто, чтобы продолжать жаловаться на С++ — не помню, когда в последний раз случались подобные сложности с кодом на плюсах, где не задействованы С-шные библиотеки.
У нас соседний отдел пишет CAD на C++ на базе плюсовой же библиотеки. Там постоянно креши и утечки памяти.
Если бы Вы привели пример последнего успешного исправления утечки памяти с выявленными причинами, то можно было бы предметно разобраться, кто виноват, и что (надо было) делать. Если есть непреодолимое желание работать с памятью в С++ самостоятельно, то все средства языка для этого в наличии, как и на заре его появления (я слышал, обычно стреляют себе в ноги). Если не получается, то может и не надо? Используйте более высокоуровневые средства языка.
Я к их коду доступа не имею (лицензия на используемую у них библиотеку ограничивает количество разработчиков, которым ее можно показывать). Но команда там очень сильная, про смартпоинтеры знают.
Но команда там очень сильная, про смартпоинтеры знают.

Это, на самом деле, пять.
Вот не надо писать CAD. Надо взять открытый и приспособить к своим нуждам.
google: Open source CAD system.
Серьёзные CADы съедают многие человеко-годы. Вот честно, Ваши коллеги поседеют, а продукт останется говном.
Хорошо бы, но зубные коронки — слишком специфичная область, что бы там подошли готовые решения.

В описанной ситуации можно реализовать алгоритм, например, на Mathcad, отладить и убедиться, что он работает. А потом, если требуется скорость, переносить его на С или delphi.

Насчет отладки C++ — если программа падает с segfault'ом, то для нее скорее всего образуется core dump файл, в котором будет вся информация о том месте, где упала программа, в том числе стектрейсы и содержимое памяти. Понять итерацию цикла, на которой произошло падение, весьма просто, если есть core dump, который загружается в отладчик.

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

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

Насчет падения компьютера от программы которая что-то вычисляет — это ну очень странно. Современные ОС уже очень давно нельзя обвалить (при условии отсутствия багов/эксплоитов, но в этом случае это делается намеренно, а не случайно), просто так вызвав что-то из программы, запущенной с правами простого пользователя. Тем более, если это просто вычисления, которые ничего кроме функций ввода-вывода и математики не вызывают. Я могу себе представить что система может например зависнуть от недостатка памяти (в Linux это проблема), но и в этом случае есть решения, например, квотирование ресурсов для программы или более аггресивный OOM-киллер. Кроме того, никакой язык от падений такого рода не застрахует.
Вот видите, это ещё и какой-то не типичный баг. Выходит, правильно я тогда решил не разбираться, а переписать на Python.
Но если зависание системы — это не совсем типичный баг для плюсов на современных ОС, то всякие проблемы с доступом к памяти, либо ub — это вещь встречающаяся повсеместно. (я говорю сейчас не только об учёных, но вообще о программистах — сейчас ub можно внезапно обнаружить и в популярных библиотеках)
Повторюсь: на С++ можно писать безопасный код, не обладая невероятной внимательностью и многолетним опытом. Автор, вам стоит немного поинтересоваться актуальными возможностями хотя бы стандартной библиотеки. Маленький пример в качестве вброса (нет явного выделения/освобождения памяти, есть контроль выхода за границы массива):
try {
    auto current_scope_object_ptr = unique_ptr<my_scientific_object>({});
    vector<int64_t> array(100);
    cout << "out of bounds item value: " << array.at(100) << endl;
}
catch (const exception &e) {
    cout << e.what() << endl;
}

В подобных ситуациях проблемы случаются обычно в местах стыковки кода на С и С++, где за вас не завернули С-шный апи в объекты (не будем здесь лезть в дебри по взаимодействию с библиотеками, собранными разными компиляторами с разными настройками). И даже в этих местах стоит использовать типичный подход С++ и чувствовать себя сухо и комфортно. Например, создаем xml-документ с помощью библиотеки libxml2:
unique_ptr<xmlDoc, function<decltype(xmlFreeDoc)>> doc(xmlNewDoc(BAD_CAST("1.0")), xmlFreeDoc);
С-шный объект корректно закончит свое существование в любом случае.
И так далее.
Тут проблема в том, что давно уже существуют C++11/C++17, давно уже существуют Core Guidlines, и т.д., и т.п., но в университетах, в учебниках «для чайников» и в онлайн-курсах все равно обычно всё построено на new и delete, char*-строках, и т.д.
Либо вообще, сначала натаскивают на чистый Си, а потом рассказывают про ООП в плюсах, и на этом всё.
Об этой проблеме на CppCon говорил Бьярне Страуструп, об этой проблеме там же говорила Кейт Грегори, но по факту традиции меняются очень медленно.
это та же проблема, что и с изучением программирования в вузах в целом. Если преподаватели информатики сами не программисты (а для всех не кодерских специальностей это так), они отстают от технологий лет на 30. Тот же паскаль до сих пор преподают, хотя язык уже лет 10 можно признать официально умершим. Если речь о с++, то это обычно даже не с++03.
Чета у меня бомбануло от этой статьи. Напишите, какое у вас образование (где учились) и в каком институте делаете такие расчеты. Просто чтобы знать.

Как тут уже в комментах говорили, вы не ученый, а гуманитарий. Юзайте гламурный матлаб и стройте там свои графики. Он никогда не падает, не теряет данные и имеет встроенные типы еще круче, чем в питоне. И да, там программировать не нужно. Совсем.

Потому что для программирования нужны мозги, особенно если программировать на с++. Задача начинается не с программирования, а с написания обоснования (тоже что и ТЗ в обычном мире). Почитайте на досуге, как представляются числа в компьютере и с какой точностью вообще возможно провести вычисления. Заранее определите границы эксперимента и диапазон значений. Предусмотрите вариант потери значащих разрядов или бесконечного цикла (судя по всему, именно это и произошло в вашем случае). Ошибки банальные, я бы сказал детские. Но кажутся совершенно непреодолимыми, если на них забивать. Компилятор с++ выдал вам ошибку, но вы даже не поинтересовались куда\почему у вас делась память. Делфи вам что-то посчитал, но вам лень разбираться, почему произошла потеря точности. Зато вот реклама питона на ура.

И да, сам работал до недавнего времени в науке. Не всегда задачи решаются. Попытка притянуть результат за уши выглядит смешно. Вот питон что-то посчитал (насколько точно другой вопрос) и уже бежим за медалькой. Иногда по результатам вычислений приходится писать отчет, что задача не вычислима. И надо снова сидеть за формулами, изобретая другой подход. И учится разбираться не только в своей области, но и в своих инструментах. А компьютер — это просто инструмент. Если вы его не хотите учить, то считайте по старинке — с помощью ручки и бумаги. И нечего писать, что с++ плох, просто вы х*евый кодер.
И нечего писать, что с++ плох, просто вы х*евый кодер

Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?


Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.


Я считаю что автор поступил рационально.

Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?

Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.

Компьютер и ЯП — инструменты. Для того чтобы добиться хорошего результата инструментом, нужно уметь им пользоваться, знать принципы его работы, имеющиеся ограничения, применимость.
Автор (внимание, аналогия) отказался от шуруповёрта в пользу молотка потому что шуруповёртом было очень неудобно забивать гвозди. К тому же его корпус достаточно быстро выходил из строя, а новый экземпляр в сравнении с молотком стоил гораздо дороже. При этом, если бы он знал что шуруповёрт работает с несколько иным видом крепёжных изделий и понимал принцип его работы, возможно он смог бы добиться лучшего результата, начав использовать шурупы вместо гвоздей.
Можно ли этот его поступок считать рациональным?
Можно ли этот его поступок считать рациональным?

По-моему, вполне.
Ситуация: есть шуруповёрт, молоток и гвоздь. Гвоздь нужно забить.


Решение автора: шуруповёртом не получилось, возьмём молоток. О, нормально!


Ваше: итак, во-первых, возьмём вместо гвоздя шуруп...

Решение автора: шуруповёртом не получилось, возьмём молоток
Не совсем. Скорее:
Шуруповёртом не получилось, напишем статью, почему использование шуруповёрта не подходит для работы с крепёжными изделиями.
Рад что хоть попытки автором забивать гвозди шуруповёртом не оспариваются :)

Ваше: итак, во-первых, возьмём вместо гвоздя шуруп...
Просто я уже давно не решал задач «забить гвоздь». А если решать задачу «закрепить изделие на стене», я вполне готов рассмотреть альтернативные технологии, сравнить их эффективность и т.п.
Причем здесь рационально он поступил или нет. Тем более, что я считаю что он поступил совсем нерационально.

Если он хочет быть ученым, то его выбор матлаб (у нас его все использовали) или вот вольфрам математика. Специально заточен под ученых, можно вводить формулы как они привыкли (что там еще в статье было) и не надо думать. Просто нажал кнопку и система все сделала сама.

А вот если он пришел на программистский портал и пытается доказывать, что с++ говно только потому что ему было лень прочитать сообщение о ошибке. Или что программа зациклилась и упала, но это не ошибка программиста ученого, а просто язык программирования плохой. И ожидает, что за его громкие титулы ученого ему все будут прощать.
отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.
лучше бы он ездить научился.
а то права купил и теперь всем рассказывает что формула 1 плоха, потому что по городу не погоняешь и передачи надо самому переключать.
а вот рено хорош, там автоматика даже думает за тебя, вообще ничего делать не надо
Просто информация для человека работавшего в науке:
а) метод стрельбы, к примеру, полагается на точное знание асимптотики функции, и должен вести счёт до попадания в небольшую окрестность этого конечного результата. Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
б) необходимая точность для гарантии сходимости выбранного численного метода расчитывается из теории, и прежде чем выделять память программно правильно, нужно заранее расчитать некоторые величины. В физике есть 3 способа оценить необходимые для такого расчёта величины: 1) теория (аналитического решения нет); 2) численное моделирование (рекурсия, см. пункт б)); и 3) эксперимент (скорость охлаждения в исследуемом процессе~10^6К/с, данных столько же, сколько у слепого котёнка). Так что, справедливо взвесив возможности, можно сказать (и даже написать отчёт) что задача неразрешима и невычислима. А можно прикинуть любую случайную длину, скажем 32 бита для начала, а уже затем увидеть где есть расходимости и поднять точность для таких «узких мест».

А то люди так много открытий потеряют… Которые ТЗ не соответствуют.
Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла

Добавить счётчик итераций, если их слишком много, значит что-то пошло не так и программу лучше остановить.

А сколько там поставить? Вот у меня был случай со стрельбой — одно значение попадает очень точно на целове, там 9.00002, что-то такое. У меня функция принимает необходимое количество знаков после запятой, и идёт по бинарному дереву вариантов производной в нуле, и такой глубины, как заданная точность. Почти сразу где-то врезается в цифру 9 и попадает в эпсилон окрестность ассимптотики. Ответ есть за 3 итерации. А чуть-чуть изменил входные данные, и уже путь до эпсилон окрестности удлинился в 10000 раз.
Если точность задана, то есть оценка в количество веток на бинарном дереве. Но если ни одно из решений не падает на асимптотику, алгоритм может подгрузить следующий знак, и там ему может больше повезти. Если бы можно было определять направление изменений в какой-то далёкой итерации, и применить аналог метода градиентного спуска, то можно было бы быстро расчитывать и контролировать наличие условия выхода. Но со сложными периодическими функциями так не выходит — от них выстреливают гармоники, которые могут сделать внезапный горб на функции, когда она уже почти прижалась к своей асимптоте. И это никак не проконтролировать, ведь теперь значение в далёкой точке может свидетельствовать о расходимости, а может и не свидетельствовать. Есть масса всяких нюансов, которые не все учитывают, и которых нет в стандартных библиотеках. Защищённый таким способом код в таких случаях может вести себя следующим образом: перебрать столько значений, сколько разрешили, и вывалиться с ответом что решение везде расходится. А незащищённый код находит сходящееся, потому что уменьшает точность, пока горб не уползёт. А время выполнения у него будет разное для разных значений — где-то медленнее, а где-то и быстрее защищённого.
А сколько там поставить?

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


Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда

Будет чёткое понимание, в каких местах алгоритма возникают проблемы со сходимостью (и временем работы). Дальше можно искать ошибки в конкретном месте или менять подход к решению. В крайнем случае можно сделать "в лоб" — убрать ограничение. Если программа не завершится — будет по крайней мере понятно, что пошло не так.

а) точного ничего в природе нет. вы должны сделать оценку вашей функции. и сравнить с точностью, с которой представляются числа в компьютере. в процессе вычислений вы должны контролировать эти величины и при расхождении немедленно прерывать цикл. иногда требуется переписать цикл, благо в с++ их несколько разновидностей.
б) именно это и есть ваша научная работа. да у вас есть научная задача, но вот как решить ее — это еще одна отдельная научная задача. (и так до бесконечности :) хотите все и сразу — так не бывает
1) численное моделирование может быть итеративным и нет необходимости сразу запускать полный расчет. сделайте несколько тестовых прогонов и посмотрите на поведение функции. при необходимости, скорректируйте программу. ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил. только гении могут пред-угодать точное значение. простым смертным приходится ковырять программу много много раз, прежде чем получить хоть какой-то результат
2) ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений. да это отдельная научная проблема. не хотите изучать компьютерные науки — ваше дело, используйте матлаб и не пишите глупых статей

кароче, вы бы у меня даже экзамен не сдали.

кароче, вы бы у меня даже экзамен не сдали.

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

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

Которые взаимозаменяемы. Можно ещё вспомнить в каком-то из языков отдельные операнды iftrue/iffalse — такие вещи нужны если вдруг употребление именно этого слова сделает код понятнее. Но потоку как-то пофиг. Вы можете реализовать один и тот же цикл как while..do, и как repeat..until. И если потрудиться учесть наличие первого прогона и форму условия, они будут эквивалентны.
ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил.

С постоянным выводом данных это не проблема. Нет никакой разницы в методах. Вопрос в дроблении кода на части. Я раздробил так, чтобы получить график. Если бы я решил по другому, и сначала бы проверил что одна итерация отрабатывает — то я бы увидел что она работает с моими начальными условиями. Это и так понятно. С другой стороны, когда я выбрал сразу много считать, я всё равно получил информацию о том что отдельные итерации с начальными значениями на входе работают — когда в консоль начали валиться данные.
ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений.

6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима. Если говорить об области применения кода, виновника торжества, то это область где даже качественное поведение функции и значения в пределах 10% точности были прорывом. Потому что экспериментальных приборов для измерения таких вещей даже косвенным образом — не существовало. Но что касается точности модели — то вы, должно быть, не знаете, как оценивать косвенную погрешность таких вычислений.
6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима.

Для типов float нет такого понятия как знаков после запятой, у них есть мантиса и порядок числа, на больших порядках числа не то что после запятой, а и целых-то нет разрядов нет. Именно поэтому падали ракеты хранящие время с плавающей точкой и плюсующие доли секунды, однажды просто там время остановливалось. У вас вообще ничего не щёлкает, когда говорят, что точка ПЛАВАЮЩАЯ?
Особенно эпично выглядят вот такие перлы:
И обнаружить (после исправления этих двух) ещё один «протекающий»* коэффициент

То есть в формулах, вы не забываете, что надо метры на секунды умножать, а не километры на дни, а тут… ПОТЁК…
UFO landed and left these words here

Отлично, задачу решили, вопросов нет.


Но зачем потом рассказывать что программы на C++ не работают, если проблема исключительно в знании С++?

Человеку (не программисту) нужно решить задачу. А не изучить язык программирования

Тогда зачем он взял инструмент, которым не умеет пользоваться? И вместо признания "я не смог", выводы — инструмент плохой. Мультфильм такой был, документальный, про мышонка, которому "кривые кирпичи подсунули". Один-в-один.

Человеку (не программисту)

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

верификация результата в науке — обязательна

Отвечу только про верификацию. Я не верю в его результат. Я не верю в его метод расчета. И я не верю в его эксперимент. Если он так проводит научную работу, как пишет статьи — то грош цена его исследованиям и его науке!

UFO landed and left these words here
Вот, кстати, про cython я бы хотел знать в то время. Но, правильно ли я понимаю, что для правильной оптимизации cython надо иметь опыт программирование на си-подобных языках?
UFO landed and left these words here
Если у вас грубо говоря основная часть кода — циклы по numpy массивам, то скорее всего большое ускорение даст numba. Применить проще, чем cython, ускорение сопоставимое.
Но по другим (наличие результата) — есть результат.

Да нет там никакого результата, если человек использует числа с плавающей точкой и не контролирует значения в промежуточных вычислениях. Хоть какой язык возьми, на выходе будет чистое везение, которому доверть нельзя, в принципе. Но тут на несколько бит язык отсыпал побольше везения и опа — годнота!
Что касается «значащих разрядов», так вы вообще написали чушь. Вы путаете питон (у которого таких проблем нет) и С/С++ (у которых такие проблемы есть).

А с этого места, пожалуйста, поподробнее. В питон завезли символьную арифметику?

Кривоватую, но да, и давно. Sympy.
Дадут ему инструмент какого-нибудь иного рода. Пусть дорогущую лазерную установку. Он решит, что ему лень/некогда/ещё что-то читать документацию к ней, и запустит наобум. Стоит отметить, вероятность вывести её из строя при таком подходе крайне высока, вот только интересно, как на него посмотрит руководство? ЯП — это такой же инструмент, разве только цена ошибки обычно дешевле, но это не значит, что к нему не нужно читать документацию.
Инструкции к лазеру: не лезть к внутренним контактам руками без антистатического браслета, не отключать стабилизатор напряжения, не светить в глаза. Одно предложение, три пункта. С этими правилами сломать установку или навредить людям уже очень сложно. Сбить настройки можно, но потом значит придётся калибровать, только и всего. Перекачать прибор, который всё время работает в инверсной населённости? Бред, даже если светить двумя лазерами друг в друга. Спалить высоким напряжением? С поставляемым с лазером стабилизатором и защитой от статики почти нереально. Разве что гвозди им забивать, тогда конечно, сломается.
Инструкции к С, С++, общие правила работы с памятью, описание стандартной библиотеки и буста — текст будет в очень много раз длиннее. И любое правило при несоблюдении может заставить программу работать неправильно из-за ub или вылета памяти. Воспринимать это как полноценный инструмент сложно, по скольку нет протых инструкций, с которыми можно быстро ознакомить человека, и оставить его работать, твёрдо зная, что он ничего не испортит.
во-первых, ошибки программиста могут быть не только в некорректной работе с памятью, и в современном с++ есть всё, чтобы избегать даже возможностей допустить такого рода ошибки. Во-вторых, изучение более сложного инструмента может окупиться в перспективе
Автор сделал неверные выводы на основе неполных данных, а значит как ученый не имеет базы определяющей причинно следственную связь.
Это отменяет его объяснение почему в научном мире питон более популярен?
Невежество порождает невежество.
В университете преподаватели, особенно, у чистых математиков, редко выходят из профессиональных программистов. Чаще всего это те же математики, которые были студентами лет 20-30 назад. Или такие же, как ТС. И как они, после всех чертыханий с устаревшим бейсиком или адой, выучили C98, так они ему и обучают своих подопечных. И я сейчас по себе сужу: когда в свет вышел C++11 у меня не приняли лабу с std::auto_ptr, потому что «надо руками память работать».

А зачем изучать C98? Зачем руками в память? А незачем. Приучи человека сразу использовать умные указатели, перемещать и ловить исключения — и код становится не сильно сложнее, чем у питона. А то, что там есть ещё указатели — пускай узнают самостоятельно. А если копнуть глубже, всякие constexpr и operator дают возможность разработчикам библиотек делать очень гибкие интерфейсы с нулевой конечной стоимостью.

А пока первокурсников заставляют printf, питон будет более популярен.
А зачем изучать C98? Зачем руками в память?

Затем, что:
std::auto_ptr, всякие constexpr и operator

при их злоупотреблении приводят к абсолютно нечитабельному коду.

Что вы понимаете под "злоупотреблениями"? Мне вот тяжело читать код с ручным управлением памятью — я от такого попросту отвык.

Да пусть даже код какой-нибудь реализации стандартной библиотеки C++ в котором чёрт ногу сломит. В тоже время с кодом движка DOOM 3, написанном по большому счёту на «Си с классами» нет никаких проблем.

Но вообще, это всё крайности и вкусовщина. Главное, что-бы удобно было лично вам и тем с кем вы работаете.

Для того чтобы использовать стандартную библиотеку — не обязательно ломать ноги внутри. Покажите код, который стал нечитаемым из-за std::auto_ptr

UFO landed and left these words here
C и С++ изучают только программисты. Естественнонаучники (за очень редким исключением) учат программирование на Делфи, а потом всякие спецпакеты. Максимум пролог будет. Там не учат С98. Там не учат что памятью в принципе можно управлять. Тем более — что нужно. Учат так: вы придумываете правильный алгоритм, компьютер его выполняет. Учат как переписать алгоритм из головы на паскаль. В дальнейшем учат параллельно матпакеты, пакеты симуляций, численные методы (теорию) и учат моделировать на практике — могут посоветовать использовать пайтон, или делфи, но ничто не мешает использовать любой язык: код никогда не смотрят, только результат в виде графиков и фазовых портретов.

Когда я год назад начал программировать на си я внезапно узнал что а) Память вообще где-то вручную выделяют б) что этим занимается программа (раньше я думал что возня с памятью — это исключительно работа ОС) в) что это не только можно, но и нужно делать в некоторых языках г) что си — один из таких языов и д) что означают бесконечные звёздочки в коде, и что такое инкремент ссылки в принципе.
До того как мне это понадобилось с си, я спокойно программировал и моделировал 14 лет на разных языках, ни разу не сталкиваясь с необходимостью высвобождать память, работать с указателями и всё в таком роде.
Использовать умные указатели и исключения — это уже следующий уровень. На тот момент, который я описал в статье, я вообще не знал о существовании прямой работы с памятью. А программировал при этом, соответственно, 9 лет (паскаль и скриптовые языки).
Я не знаю где вас учили, но на моём естественно-научном факультете сначала был курс C# (2 года). А теперь вообще идёт курс Java EE c Хадупами и всем фаршем.

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

Не хотите программировать? Для вас есть Maple, Mathematica и т.д. И то… в этих пакетах тоже дофига нужно писать.
C# точно так же язык со сборщиком мусора. Это не C++. Хадуп нужен для баз данных. Редко необходимая вещь в симуляциях. Разве что большой банк данных вытащить… Но что дальше с ними делать? Мэппить? Это разве только для статистики может пригодится, не для численых расчётов, как мне кажется.

Программирование надо знать — но совсем не обязательно знать системное и низкоуровневое программирование.
Я про это и пишу. Это может показаться странным, но в этом моменте я с вами не спорю. У плюсов действительно не самая лучшая репутация, особенно, из-за старых суеверий, которые всё ещё живут в умах тех специалистов, которые столкнулись с плюсами ещё в 90-х — и не следили за языком с тех пор, даже если на нём программируют по сей день. Далеко ходить не надо, вот пример:
HenadziMatuts
Затем, что: std::auto_ptr, всякие constexpr и operator при их злоупотреблении приводят к абсолютно нечитабельному коду.
Ответ прост. То, что происходит внутри библиотеки — проблема разработчиков библиотеки, не учёных. А вовне, используя using, можно отправлять уже красивые имена.
using IntegerData = std::unique_ptr<std::vector<int>>;
Нас же не интересует, как устроен кеш процессора, какие у него там отступы в нанометрах. Нам важен результат его работы: он угадал или нет. То же уровнем выше: если вокруг вашего определения полным полно ненужных пользователю ключевых слов, либо с помощью форматирования выделите нужное, либо с помощью псевдонимов и макросов спрячьте ненужное. Хотя почему «либо»?..

Современный С++ позволяет писать библиотеки для работы с математикой так, чтобы наши чисто программистские замуты не трогали пользователей библиотек — учёных, в нашем случае. Сегодня вполне можно написать библиотеку, в которой будет синтаксис, к примеру
auto I = Integral<_1>( [](Numeric & x){ return x^6 - x^log(1/x); } );
double s = I(From(-6), To(-9));
auto D = Derivative<_2,_3>( FUNCTION(x,y,z){ return x^y^z^2; } );
vector<double> v = Parallel::map(D, 25, Interval(-1, 1, 0.1), Interval(-25, 25, 0.01));  
Ясно дело, что от разработчиков библиотеки это потребует усилий, что далеко не везде записи будут лаконичными (в силу ограниченности набора символов, хотя бы), и ошибки компиляции, в ряде случаев, будут совсем не дружелюбными (до с++20, как минимум). Но это не тот Ад и Израиль, которым можно пугать маленьких детей, это не
void *d = realloc((void*)&data, sizeof(Tuple_struct)*STANDARD_RESERV_MEMORY);
Я рад что С развивается, но вот направление этого развития всё ещё подчиняется идеологии минимализма (ака сделай сам) и того самого фирменного си-стиля со звёздочками (я плотно не слежу, но читал обзоры на стандарты, и по ним сложилось именно такое впечатление).
Лично я уже не так боюсь С как раньше, мне в этом помог видеокурс с растолкованием разименования, системы памяти и того, зачем вообще создали С, но я понимаю что для приблизительного понимания кода С, или С++ нужно: потратить хотя бы два месяца на разбор базы, месяц покодить, потратить ещё месяц на разбор ошибок в своём коде с книжками в руках, и только к концу 4-5 месяца начинаешь только понимать что вокруг происходит.
На Пайтоне же, порог вхождения примерно такой: умеешь упорядочить свои мысли и написать блоксхему работы желаемого кода — это уже больше необходимого чтобы взять и написать. Это очень удобно для людей, которые тратят кучу времени на другие сферы своей жизни, работая не программистами, а, скажем, учёными, которым необходимо время от времени напсать какую-то программку. Проблемы с Пайтоном у меня возникают реже не потому, что я лучше его знаю, а потому что интуитивно написанный код в нём работает гораздо чаще, т.е. надо знать минимум специфики языка, чтобы эффективно им пользоваться.

Сам я нигде не работал 3 месяца, пока изучал C# — а потом выкраивал время чтобы освоить новый прикладной пакет для вычислений, пока со всех сторон наседали проекты, которые обязан делать. Но я понимаю что в таком режиме работать может далеко не каждый, и, вспоминая старые добрые времена, понимаю что освоение Пайтона заняло у меня 2 дня. Один день — прочитать методу после пар. 2 день — написать «привет, мир», мешалку массивов, казуальную игру и смоделировать систему с динамическим хаосом. Язык реально понятен как пень. С си пришлось осваивать какие-то новые концепции памяти и так далее…
Вот правду говорят, что на изучение нового языка после первого тратишь меньше времени. Я реально после паскаля все остальные быстрее осваивал. Кроме си. Так что он, хоть уже и не пугает, но вызывает больше неприятных ассоциаций, чем пайтон (кстати, даже на джулию я больше времени в итоге потратил, чем на него).
Что-то вы в кучу намешали Си, С++ и C#, хотя это три разных языка.
Как бы помягче? Вы ничего не знаете. Да, пожалуй так. Получилось почти даже и без мата.

Сложность современного C++ возрастает практически линейно от сложности решаемой задачи. На самом деле, беда в том, что курса о плюсах, который был бы именно по C++17, его нет. Всё тянет корень от Си, что в корне не верно. Язык ОЧЕНЬ изменился. И то, что было актуально 20 лет назад «со звёздочками», сегодня может быть напрямую вредным для работы приложения. Вместо тысячи слов, самый тупой пример. Да, это всего лишь сортировка динамического массива. Но она не критично отличается от Питона, при этом максимально выразительна и предсказуема для разработчика.

Тут же можно возразить, мол, «Hello, World!» на многих языках тривиален. Да, соглашусь. С++ не простой язык, в этом легко убедиться, если посмотреть, как сделан std::tuple. А не надо ходить и смотреть. Вы же не ходите смотреть, как в питоне сделаны кортежи. Вы ими просто пользуетесь. Вот и в плюсах просто пишите
using Number = std::tuple<int, std::string>;
Number one{1,"ырас"}, two{2,"дывас"}, three{3,"тэрис"}, four{4,"мноха"};
и не выделывайтесь! А то кодют тут разные, понимаешли, по свежерефакторенному, работать не дают!

Единственный минус, из коробки идёт небольшой функционал. Короля играет свита, а питон — ничто без его импорта. У плюсов тут всё сложнее: есть и boost, и Qt, которые совершенно меняют взгляд на мир, но об этом тоже нужно узнать и прочесть. Хотя Qt есть и под Питон, PyQt называется, так что с концепциями можете ознакомиться и в привычной для вас среде.

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

Мне на секунду почудилось там лямбда выражение…
Ну, и, в конце концов, не врите. Вы не освоили питон за вечер.

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

Учебники по плюсам в основном старые, но это полбеды. Основная — что часто, когда открываешь чужой код (не важно, двух, или 10-тилетней давности), то видишь всё те же звёздочти и си-стайл. Я ещё ни разу в работе не столкнулся с новыми фичами, всё делают пойнтерами и ещё очень любят небезопасные оптимизации.
Не почудилось. И тут оно тоже должно было вам не почудиться. А если вы очень внимательны, то целых два раза.
Вы ничего не знаете о современном C++, и именно поэтому вы были восприняты в штыки. Вы читали статьи? Очень даже сомневаюсь.
Это, безусловно, соломинка в вашем глазу: раз уж вы взялись изучать живой язык, нужно брать только свежие статьи и книги, а не перечитывать фолианты прошлого века.
Но это же бревно в наше сообщество: ведь это мы не можем выпустить толковый учебник по современным плюсам без мохровых плесневых шуб, мы не можем вытащить его на поверхность, мы не можем проконтролировать, чтобы в библиотеках были только свежие работы по нашему языку.

0xd34df00d, я не занимаюсь численными методами, потому привёл первое, что попалось при гуглении. Если выбор был не очень, что ж, тогда посыпаю пепел своими головами.
Под никсами писал мало, и оверкоммит не встречал. Наверное, потому, что он по умолчанию отключён. Но, можно очень противный вопрос? А какой гений от администрирования его включает на машинах с агрессивным использованием памяти? Мне в принципе тяжело придумать вариант, кроме виртуальных машин, когда нужно выдавать больше памяти, чем есть. А если у вас расчёты на физическом оборудовании — или на виртуальных устройствах, зачем вы делаете себе жизнь веселее с помощью предметов фаллической формы?
Под никсами писал мало, и оверкоммит не встречал. Наверное, потому, что он по умолчанию отключён.

Нет. Обратите внимание, какая именно опция «is the default».

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

Учитывая предыдущее, этот вопрос ИМХО уже чуть-чуть отвечен, но самая ирония в объяснении опции 1 по ссылке выше.
Наверное, потому, что он по умолчанию отключён.

Он не может быть отключен — это базовые свойства платформы. Выключение оверкоммита — есть не его отключение, а включение эмуляции допотопного поведение. По поводу того, что он «включен» по у молчанию — уже сказали.

А какой гений от администрирования его включает на машинах с агрессивным использованием памяти?

Гению вообще не нужно ничего трогать, особенно то, назначения чего он не понимает.

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

Правильно, ведь без понимания фундаментальных вещей — их и не придумать, хотя они рядом.

Первое — память не выделяется. Второе — примеры рядом.

Берём gcc, берём заполнение вектора, заполняем его на чуть больше 1 гигабайта — получаем capacity 2гигабайта и size чуть больше 1 гигабайта. Занимает программа памяти чуть больше 1гигабайта — почему?

Да что там далеко ходить. Запускаются в системе сотни процессов и тысячи потоков со стеком 8мб по дефолту. Почему всё это запускается и не жрёт десятки гигабайт памяти?

А если у вас расчёты на физическом оборудовании — или на виртуальных устройствах, зачем вы делаете себе жизнь веселее с помощью предметов фаллической формы?

Эмуляция лишь эмуляция, и даже если её включить — она особо ничего не изменит.

Как бы вам помягче сказать, вот вы рассказывали выше человеку о том, что он ничего не знает и делает выводы, вот я могу вам то же самое сообщить. Вы НИЧЕГО не знаете и делаете то же самое. Как у человека устаревшие на 5лет представления о С++, так и у вас — устаревшие лет на 30 представления о памяти.

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

Кроме того, на плюсах оверкоммит встретить не просто, ибо оператор new для нетривиальных классов тут же производит инициализацию вызовом конструктора. А это тут же повлечёт физическое выделение памяти и, как следствие, бросок исключения. То же верно для std контейнеров, единственный способ наткнуться на оверкоммит — вызвать reserve на огромную сумму, потому что остальные тут же заполняют память.
Вероятно, потому и не встречал оверкоммит — не писал на Си-с-классами.
Охлади траханье. Поведение виртуальной памяти мне известно.

Прохладные истории.

Мне не было известно, что никсы позволяют оверкоммит по умолчанию, без особых системных вызовов.

Опять же, такую ахинею никто, кому известно что-то о памяти — не напишет. И в очередной раз ты это подтвердил.

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

Очередная ахинея, которая подтверждает мои слова выше. Инициализация производится в юзерспейсе, а значит — ничего не даёт.

А это тут же повлечёт физическое выделение памяти и, как следствие, бросок исключения.

Нет, ахинея просто невероятных масштабов. Валидный пейджфолт не может НИКАК вернуть НИЧЕГО, особенно какие-то юзерспейс исключения.

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

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

Особенно меня веселит «огромную сумму» — какую? На чём основаны эти глупые утверждения?

Вероятно, потому и не встречал оверкоммит — не писал на Си-с-классами.

Каждая следующую отмазка всё невероятней. Да самое использование слова «оверкоммит» — признал полной несостоятельности, ведь человек просто ретранслирует базворды, значения которых он не понимает.

Мне на секунду почудилось там лямбда выражение…

И что? Простейшая же штука.

И что? Простейшая же штука.

Просто у человека открылись глаза на современный C++. В универе местных книгах про наличие лямбд в нынешних плюсах ему не расскажут.
Всё тянет корень от Си, что в корне не верно. Язык ОЧЕНЬ изменился.

Да, язык изменился, но это ничего не изменило. Он как был си — так им и остался, а значит почти вся базовая логика( именно логика языка, а не stl, либо иной либы) — есть эксперт из си.

Почему пришлось кастылить функторы, а не использовать функции? Правильно, потому что функции полностью экспортнули из си, где это просто имя — имя некого объекта/символа в объектнике. А перегрузку просто прикостылили конкатом с тектовым представлением типов аргументов. А вот структуры уже были типами в си, а значит стали ими и в С++.

И о каком понимании С++ может идти речь, без понимания си.

Да, соглашусь. С++ не простой язык, в этом легко убедиться, если посмотреть, как сделан std::tuple.

Магия порождает магию. А далее нам нужно обойти этот tuple, и нам опять нужна магия. Можно, конечно, найти готовую и в новые стандарты потихоньку вводят некую базовую магию, но — шаг влево/вправо и всё.

Говорить о том, что можно нормально использовать подобные вещи в полной мере в С++ — без понимания подобной магии — не очень корректно.

И проблема в том, что tuple — это кастыль, который сделан не благодаря, а вопреки. Нельзя сказать о том, что подобные решения красивы, функциональны и вообще необходимы. Да, не имея ничего большего — подобные решения приемлемы, но не более. И это слабость С++ в глазах остальных людей, да и объективно это так.

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

Но им ненужно это, поэтому им абсолютно неважны все эти нюансы. Мне нужно записать строку и число, а как это работает — неважно. И все эти статические заморочки — им не интересны.

По поводу примера. Тут ничего такого нет, а вернее видно только интерфейс, слабость которого — прямое следствие слабости С++. Т.к. шаблоны не типизированы, и любой тип T — есть ничто иное, как множество всех возможных типов, то мы просто теряем перегрузку — остаётся только по числу аргументов, либо кастыли. Именно поэтому я не могу передать туда контейнер.

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

Допустим, я бы мог просто отнаследовать все контейнеры от одного begin/end интерфейса и получить sort(vec) — нахаляву, как и sort(begin(vec), end(vec));

За примерами так же далеко ходить не надо. Шаблонный аргумент теряет всю информацию о типе, а значит — узнать о том, что можно там будет может только компилятор. Мы теряем и комплишн, и какую-то визуальную оценку.

Все ругаются на макросы в си, но шаблоны не далеко от них ушли. Да, как аргумент мы можем передать только тип, но тип любой. Это мало отличается от «можно передать всё».

Все ругаются на макросы в си, но шаблоны не далеко от них ушли. Да, как аргумент мы можем передать только тип, но тип любой. Это мало отличается от «можно передать всё».

во-первых, шаблоны можно параметризовать еще и численными аргументами. Во-вторых, можно накладывать ограничения на параметры шаблонов. В-третьих, макросы не позволяют SFINAE. В четвертых, динамически можно сделать почти всё что угодно, вот только а. пока рантайм резиновый, и б. полностью теряется возможность статической проверки кода на корректность. Пятое — совсем не обязательно понимать как реализован std::tuple или любой другой stl класс чтобы им пользоваться. И последнее: зная плюсы на уровне брошюры «с++ за неделю» не беритесь судить о том, как он похож на си. Скорость разработки на этих языках отличается в разы.
во-первых, шаблоны можно параметризовать еще и численными аргументами.

Не во-первых. Мало того, что это полная несуразица, ведь «параметризовать» можно не только численными аргументами и типами.

А во вторых, говорилось об аргументе-типе, а не о том, что только он там и есть.

Во-вторых, можно накладывать ограничения на параметры шаблонов.

Нельзя. Подобные рассуждения сродни «а int не переполняется, ведь мы может накостылить проверку переполнения», только вот к инту это не будет иметь никакого отношения. Так же и тут, да, некое убожество накастылить можно, но это не «есть» — это прикручено слева.

Раньше и вариадики были, ведь их точно так же можно было накастылить. Только что из этого следует?

Есть — это T extends interface из той же жавы, либо концепты. Вот люди идиоты, оказывается всё есть, а они уже 5лет пилят концепты. Тутошним експертам, конечно, виднее — что есть, а чего нет.

Если кто не понимает, почему это маразм — я поясню. Прикрутить проверки слева — можно к чему угодно и договориться до чего угодно.

void f(int a, int b);
#define f(a, b) f(a, b)


Типичный тому пример. Проверяются ли типа при «вызове» макроса? Да, проверяются ли они на уровне макроса? Нет.

В-третьих, макросы не позволяют SFINAE.

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

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

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

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

Ваши рассуждения о резиновый/не резиновый никого не интересуют, ведь они попросту противоречат реальности. Жава есть? Питон есть? Пхп есть? Значит для них ваши рассуждения о «резиновый» попросту не котируются, ведь для них — он резиновый.

Второе, опять же, кто вам сказал, что кому-то нужны ваши статические проверки? Люди живут без них и ничего. И именно об этом я писал. Людям не интересны ваши статические заморочки, и именно поэтому — для них ваши рассуждения не стоят ничего.

Вас не спрашивали о том, чем отличается статический и динамический интерфейс. Вы всё напутали.

Пятое — совсем не обязательно понимать как реализован std::tuple или любой другой stl класс чтобы им пользоваться.

Опять же, очередной срыв покровов, который в очередной раз — полностью неадекватен. Я уже отвечал на это. Но зачем читать? Надо же заспамливать меня ахинеей.

tuple — это магия(некие кастыли, которые позволяют получить некий функционал, но обходными путями). Притом — магия эта именно в интерфейсе, а
не в реализации. Магию в интерфейсе нельзя скрыть от пользователя. Нельзя просто так взять и обойти tuple. Да, можно написать хелперы — их потихоньку пишут, но — это ничего не меняет. Тот же apply есть только в 17крестах, но — сослаться на него у вас не выйдет. Ведь для этого — вам нужно будет ограничить «современный С++» стандартом 17года.

И последнее: зная плюсы на уровне брошюры «с++ за неделю» не беритесь судить о том, как он похож на си.

Эта аргументация. Когда сказать нечего — наспамь ахинеи(откровенное враньё, подмена понятий и прочие манипуляции), а потом расскажи о том, что кто-то чего-то не понимает. При этом — не приводи ни единого аргумента.

1) И что такого можно сделать концептами, чего нельзя добиться SFINAE? (Красивые ошибки компиляции не в счет))
2) Автодополнение — действительно аргумент. Надеюсь, с появлением концептов проблема решится.
3) А еще есть сортировка с неопределенным временем работы (aka Random sort). Но если вам хочется, чтобы программа работала быстро, вы не будете её использовать, не так ли? Много на питоне или пхп, баз данных написано? Или, к примеру, ОС?
4) Т.е. тратить время на написание типов, которые часто сводятся к auto, вы не хотите, а фиксить всякие "too many values to unpack", "int is not iterable" и прочие "TypeError: null has no properties" хотите?
5) Кишки кортежей — это да. Мне кажется, чтобы что-то использовать, нужно это что-то изучать

1) И что такого можно сделать концептами, чего нельзя добиться SFINAE? (Красивые ошибки компиляции не в счет))

Что можно написать на С++, чего нельзя написать на асм? Эта рассуждения глупы, ведь неважно что можно, важно то — как можно. И это как — является ключевым. А так да, всё можно сделать кастылями, но является ли это аргументом?

Но если вам хочется, чтобы программа работала быстро, вы не будете её использовать, не так ли?

Вот вы мне объясните, зачем вы спорите с кем угодно, только не со мной? Я где-то что-то отрицал, где-то что-то подобное предлагал, либо это отрицал?

Не надо юлить. Не существует цензурных слов, которые опишут всё то, что я думаю о питоне, жаве, либо пхп. Но дело не в этом — я не обсуждаю пхп/пистон. Я обсуждаю конкретные рассуждения и отвечаю только за то, что писал я, не за то, что вы там придумали себе.

У людей очень странна реакция — они просто осознать не могут возможность, что кто-то может критиковать их. Мышление людей заканчивается на «если критикует — он адепт другой веры, а значит я могу ему сказать „ты не осилил“», и это даже работает( иногда).

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

Много на питоне или пхп, баз данных написано? Или, к примеру, ОС?

И? Вот вы заметьте — вы спорите с кем угодно, только не со мной. Мы где-то обсуждали ОС, базы данных? Нет.

Я больше скажу — те, с кем я спорю — не имеют никакого отношения ни к ОС, ни к базам данных, и они их точно так не напишут. Достаточно посмотреть на перлы выше. А особенно «я уже забыл как работать с памятью», вернее «я даже и не помнил».

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

Т.е. тратить время на написание типов, которые часто сводятся к auto, вы не хотите, а фиксить всякие «too many values to unpack», «int is not iterable» и прочие «TypeError: null has no properties» хотите?

Что? Опять какие-то ответы, адресованные явно не мне. Откуда взялось какое-то написание типов, откуда взялись все эти строчки, которые я «хочу фиксить»?

Кишки кортежей — это да. Мне кажется, чтобы что-то использовать, нужно это что-то изучать

Изучить можно всё что угодно, и как штаны через голову натягивать — только вот зачем? Мы это обсуждали? Нет.

Говорилось совсем о другом. Кто-то утверждал то, что «понимать не нужно», хотя это неправда. Понимать нужно, но всё это понимание — ненужно. Да, ты обязан его использовать — ты заложник убогости, но это не делает его нужным, красивым, удобным, либо необходимым.

Язык не умеет в рефлекшен, но можно через одно место накастылить tuple. Пусть и полное убожество, но всё же — работает. Это очень показательно, как люди недовольные тем, что всё ограничивается критерием «лишь бы работало», но при этом руководствуются им же. Пистон не быстро, но работает. tuple убого, но работает. К чему мы с таким подходом придём?

И это крайне показательно. Люди попросту не знают язык, именно поэтому и игнорируют мои вопросы, мои тезисы, мои примеры и пытаются спорить сами с собой.

Но ведь фанатизм он такой — его уровень обратно пропорционален пониманию языка. Вот мы и получаем вылезших из-за парты екпертов, которые заучили пару трюков, повторяют какую-то ахинею про «С++ дано не си», но ответить на банальные вопросы не могут.

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

Что можно написать на С++, чего нельзя написать на асм? Эта рассуждения глупы, ведь неважно что можно, важно то — как можно.

Последовательность событий:
1. вы говорите, что шаблоны принципиально ничем не отличаются от макросов и у них нет проверок типа
2. вам приводят доказательство обратного
3. вы пишете выше процитированный вброс
4. вы пишете о том, что люди спорят не с приведенными аргументами
Запишитесь на мрт
Что? Опять какие-то ответы, адресованные явно не мне. Откуда взялось какое-то написание типов, откуда взялись все эти строчки, которые я «хочу фиксить»?

речь о том, что в динамически типизированных языках в отсутствие статических проверок на корректность типов часто выскакивают ошибки несоответствия типов, и выскакивают они в рантайме. Итого код надо покрывать тестами там, где достаточно статических проверок на соответствие типа. Ваш КО
1. вы говорите, что шаблоны принципиально ничем не отличаются от макросов и у них нет проверок типа

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

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


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

И самое интересное — зачем мне вообще эту ахинею толкать? Я задал конкретные вопросы — где я писал что-то из того, что вы пытаетесь ко мне привязать? Я понимаю, что вы пытаетесь ретранслировать шаблонные ответы, а для этого — меня надо подбить под какой-то шаблон( в частности за адепта динамически типизированных языков), но не выйдет.

Итого код надо покрывать тестами там, где достаточно статических проверок на соответствие типа.

Итого — это никого не волнует. Меня не интересуют подобные рассуждения, ведь я не обсуждал тут статическую/динамическую типизацию.

Была чёткая тема — статический интерфейсы и убогость крестов, которая не позволяет их реализовывать нормально. И я уже так же говорил, что никого не интересуют причины подобного. Есть факт, а всё остальное — никого не волнует. Ваш слив с таппла на вариант — типичный тому пример.

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

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

вот только вариант гарантирует возможность обработки всех возможных содержащихся в нем типов.
И что это за глупый маразм я вижу в ответ? На что это отвечает? Что из этого следует? К чему это написано? Да просто так, лишь бы что-то написать.

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

Типичный тому пример. Проверяются ли типа при «вызове» макроса? Да, проверяются ли они на уровне макроса? Нет.

std::enable_if позволяет накладывать ограничения на шаблоны. Рекомендую курить до просветления
Мда, подобный идиотизм меня умиляет. Человек попросту не способен понять того, что ему написали и начинает ретранслировать знакомые ему базворды.

я учил плюсы несколько лет, посещал конференции и смотрел видео докладов не для того, чтобы какой-то выскочка попрекал меня баззвордами.
Жава есть? Питон есть? Пхп есть? Значит для них ваши рассуждения о «резиновый» попросту не котируются, ведь для них — он резиновый.

И много из себя представляет питон без биндингов к си/с++ модулям? И много где вы запустите джаву кроме десктопа? И много где используется пыха кроме форумов? На плюсах можно писать буквально всё, в отличие от всех динамических языков
Второе, опять же, кто вам сказал, что кому-то нужны ваши статические проверки? Люди живут без них и ничего.

угандийцы тоже живут.
Нельзя просто так взять и обойти tuple

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

обойти таппл можно и в с++11. Сложно, но можно. Как я уже сказал: зачем? Если для задачи достаточно контейнера вариантов, почему не воспользоваться им?
Очередной клоун.

std::enable_if позволяет накладывать ограничения на шаблоны. Рекомендую курить до просветления

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

Уровень маразма находится где-то в районе рассуждений о том, что в жс есть перегрузка функций, ведь typeof'ом можно что-то подобное накастылить.

Примеры я уже показывал, но они в очередной раз были проигнорированы.

void f(int a, int b);
#define f(a, b) f(a, b)


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

Меня это мало волнует. Когда клоуну ответить нечего — начинаются рассуждения о том, что он что-то там много лет учил, и что-то там смотрел. Есть что ответить — отвечай, а нету — твоя клоунада меня мало волнует.

И много из себя представляет питон без биндингов к си/с++ модулям? И много где вы запустите джаву кроме десктопа?

И много из себя представляешь ты, без готовой лапши? Ничего. И это ничего не меняет. Тебя не об этом спрашивали. Дак и тому же, как-то ты быстро слился на неведомый С/С++ с обсуждаемого тут «современного С++». Хотя что ещё ожидать.

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

Опять же, типичная шаблонная ахинея. Тебя не спрашивали о том, что можно, либо не можно написать. И что же ты слился на пых? Куда пропала та же жава? Тебе говорили о том, что никому не нужны твои рассуждения, ведь они противоречат реальности. Рантайм резиновый, и множество людей с этим живёт. Твои рассуждения в их реальности не котируются, а их реальность куда более реальна, нежели твои шаблонные лозунги.

угандийцы тоже живут.

Аргументы, такие аргументы.

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

Пошли очередные мазы. Всё, на что у меня нет ответа — не нужно, при этом нет ни единого обоснования подобному трёпу.

Клоуны настолько неадекватны, что противоречат реалиям того же языка. Клоун орёт «всё есть», а люди пилят концепты. Вот ведь идиоты. Клоун орёт, что «обходить таппл не нужно», но в стандарт добавляют хелперы, которые реализуются через tuple expansion, что и есть его обход.

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

обойти таппл можно и в с++11.

И? Я где-то утверждал обратное?

Сложно, но можно.

Неможно. В рамках контексте предполагается решение «без магии», а не любое решения.

Как я уже сказал: зачем?

Распакуй таппл в набор параметров. Типичный кейс, который ввели в стандарт.

Реализуй любую операцию поверх таппла — ничего не сможешь, кроме уже реализованного сравнения.

Если для задачи достаточно контейнера вариантов, почему не воспользоваться им?

Я нихрена не понимаю, что за «контейнера вариантов» и каким боком он тут взялся, но всё же.

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

Массив вариантов — такое же динамическое решение, и это очередной слив.

К тому же, это очередной слив ещё и тем, ведь вариант это так же 17 кресты, а значит мы автоматически множим предыдущие на ноль и это ничего не меняет.

Да и куда делся any?

Рантайм резиновый, и множество людей с этим живёт.

напиши на пыхе бпф, чтоб окно 65к за 1 мс считал. Потом говори какой рантайм резиновый.
Клоун орёт «всё есть», а люди пилят концепты.

Концепты — синтаксический сахар. Естественно он полезен, но и без него жить можно.


Ок. Не могли бы вы предложить ваш вариант реализации кортежа — убийцы нынешнего?

Концепты — синтаксический сахар.

Маловероятно, даже для того вида, в котором они существуют сейчас.

Естественно он полезен, но и без него жить можно.

Естественно, С++ полезен, но и с асм«ом жить можно. Дальше что? И да, концепты не сахар, а sfinae-кастыли — не решение.

С таким успехом — можно всё что угодно записать в сахар. Молоток то же сахар, ведь задолбить гвоздь можно и микроскопом, дальше что? А ничего. Это просто полный неадекват.

Есть решения, а есть костыли. Если раньше что-то решалось костылями, а теперь даётся нормальное решение, то оно не становится сахаром, тем более, что оно намного мощнее костылей.

Ок. Не могли бы вы предложить ваш вариант реализации кортежа — убийцы нынешнего?

Кортежи — это про рефлексию, а не про концепты. Кстати, рефлексия тоже сахар?

И да, очередной идиотский вопрос. Хотя о чём я говорю, ведь ваши ответы — типичный заспам неадекватом. Я говорю о том, что в крестах нет средств для реализации вменяемых статических интерфейсов, а мне несут какую-то ахинею про „а где ваш вариант?“. Шаблон сломался? Это такой же полный неадекват.

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