Comments 430
Разные задачи, разные ситуации — в одном из проектов программка на C полтора месяца считала коэфициенты для алгоритма обработки данных с радара (на разогнанном i7 «x» процессоре с водяным охлаждением). Python в этом случае был бы вообще нерациональным выбором
Если вы пишете код на 1/2 раза — почему-бы не объявить все «вариэйблс» «экстендедами», чтобы оно не падало? Ну и в статье всё-таки писать «переменные типа extended».
1) Если решается интегродиффур, то нужно вычислять значение из массива всех предыдущих, т.е. само выделение памяти уже грузанёт систему. (например — если расчитав изменение теплоёмкости, вы хотите сверить итоговую полученную теплоту с экспериментом и проверить правильность симмуляции — это к дальнейшему использованию этого же кода)
2) В данном конкретном случае предыдущие значения были не нужны, но extended не хватило бы. Нужны были именно операции вычислений над длинными числами.
2) В данном конкретном случае предыдущие значения были не нужны, но extended не хватило бы. Нужны были именно операции вычислений над длинными числами.
С куска про C++ просто бомбануло.
а) «у вас нет гарантий что лог сохранится, в связи с падением ОС» Как выполнение пользовательской программы может привести к падению ОС? На Linux бывало, что память заканчивается и вываливаются какие-нибудь штуки, которые ошибочно считают частью ОС (например, какие-то куски GUI). Но даже такого я уже долго не встречал. Кстати в этом сценарии Python вешает систему с таким же успехом, причем из-за своей любви к отжиранию памяти это произойдет быстрее.
Что мешает вывести лог в файл, чтобы его даже после падения посмотреть? Почему вы считаете, что дебагер — это стартануть с первой инструкции и жать F(цифра) до того места когда упадет?
Про «кроличью нору»: сам видел, как люди включают тот же дебагер и начинают входить все глубже и глубже в какие-то дебри системных библиотек. Вопрос: зачем? Наличие ошибки в таких местах маловероятно. В первую очередь нужно понять, правильно ли вы вызвали функцию (нулевые указатели и т.п.). Всегда есть valgrind, memory-sanitizer для поиска проблемных мест с перезаписыванием чужой памяти и т.п.
По-поводу неожиданных падений. Неужто в python не встречали такой же штуки? Приходишь через час, а там уже все лежит и написано «nonetype is not iterable»? Имхо, если вы не умеете писать программы, которые работают, то 1) никакой язык вам не поможет 2) тупо сохраняйте результаты вычислений регулярно на диск, чтобы потом продолжить не с нуля.
а) «у вас нет гарантий что лог сохранится, в связи с падением ОС» Как выполнение пользовательской программы может привести к падению ОС? На 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. Тут знание языка не поможет, нужно ещё и знание ответов, до того как мы их ещё посчитали.
Так что думается мне, что ваши претензии к умению учёных писать программы не оправданы.
Код на винде, по крайней мере, может залезть в область памяти с кодом ОС, и крашнет её. Я помню, как мы с одноклассниками нечаяно 2 компа на уроках информатики, причём не на си писали.
Вывод в лог файл — у вас никогда не пропадали данные из документа, если он был открыт когда выдернули штепсель? Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце. Тогда будет 100% гарантия, и очень неудобная система записи.
Исправлять в стандартной библиотеке ничего не надо. Но понять что не так с кодом, который писал сам — надо. И если ошибка заводит туда, то там где-то и содержится проверка, которую данные не проходят. Особенно сильно эти мучения касаются картинок и строковых файлов, с числами, конечно, попроще.
Касательно падений Python — ни разу не падал на долгих вычислениях. Ошибался я, конечно, и на Python, кто не ошибается? Но вот разбирался быстрее.
Касательно кодов — все три были написаны не-программистами, а учёными. Которые знают как должны работать алгоритмы, и лексику этих трёх языков. Но интуитивный «наивный» код на пайтон почти всегда работает так, как ожидается. Аналогичный код на паскале далеко не всегда работает корректно. Ну а наивный код на си почти 100% даже не скомпилируется без каких-то специальных знаний.
Плюс к тому, на примере описаной задачи видно, что предсказать что где-то там на этапе исполнени возникнет в опасной близости расходимость решения диффура — нереально. И для языков вроде Пайтон это не проблема, а в си — для оптимального решения двух диффуров понадобится по разному выделять память, причём вам заранее неизвестно на что именно её понадобится больше. Вы видите число — а компьютер видит 32 или 64 и более битов. Пайтон немного сглаживает это недопонимание, а си — нет. В итоге вы просто переписали правильное уравнение, и вдруг выясняется, что когда а в диапазооне от 0.1 до 0.3 вам нужно выделять в два раза больше памяти на B и C, а затем обрезать результат их умножения, или деления в короткий тип… А затем выясняется что когда а > 0.3 вам надо делать это не с B и C, а с D и F. Тут знание языка не поможет, нужно ещё и знание ответов, до того как мы их ещё посчитали.
Так что думается мне, что ваши претензии к умению учёных писать программы не оправданы.
UFO just landed and posted this 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. Компьютер по своей сути — большой калькулятор.
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. Соответственно учёному нужно, чтобы язык общения с этим калькулятором был максимально приближен или к его предметной области, или к используемому мат.аппарату. Что мы и видим в исходной статье.
4. Если инструмент отвечает требованиям п.3, то это означает, что наш абстрактный учёный с большой долей вероятности «умеет писать» нужный ему код. То есть обладает необходимой квалификацией.
5. А вот «писать код» на уровне системного программиста он не умеет. И его квалификация не позволяет этого делать.
На мой взгляд тут противоречий нет.
И если вы в своей практике используете компьютер для других целей и являетесь не прикладным разработчиком, то это не означает, что нет людей, использующих компьютер как «большой калькулятор», практически по его прямому предназначению :)
1. Компьютер, он же ЭВМ, это устройство предназначенное для выполнения вычислений. В первую очередь. Наличие в нём логических операций (введённых, как ни странно, тоже для управления расчетами) позволяет ему выполнять функции управляющего устройства или устройства коммуникации.
2. С точки зрения ученого естественнонаучника — это и есть большой калькулятор, который позволяет ему обсчитывать результаты, выполнять моделирование, рассчитывать прогнозные значения.
3. Соответственно учёному нужно, чтобы язык общения с этим калькулятором был максимально приближен или к его предметной области, или к используемому мат.аппарату. Что мы и видим в исходной статье.
4. Если инструмент отвечает требованиям п.3, то это означает, что наш абстрактный учёный с большой долей вероятности «умеет писать» нужный ему код. То есть обладает необходимой квалификацией.
5. А вот «писать код» на уровне системного программиста он не умеет. И его квалификация не позволяет этого делать.
На мой взгляд тут противоречий нет.
И если вы в своей практике используете компьютер для других целей и являетесь не прикладным разработчиком, то это не означает, что нет людей, использующих компьютер как «большой калькулятор», практически по его прямому предназначению :)
Вы проигнорировали моё утверждение о том, что калькулятор это такое устройство, которое не требует квалификации от пользователя. Если вы с этим не согласны, скажите прямо, ваша позиция будет понятнее.
Питон из статьи не ближе к предметной области, чем С++. И к используемому мат аппарату тоже не ближе. Питон из статьи просто производит впечатление языка, который требует меньшей квалификации. Но это обманчивое впечатление — автор написал, что он написал код, который, в отличии от кода на C++ не упал. Почему — непонятно. Явно в коде есть какие-то проблемы, которые Питон маскирует, а С++ нет. Может это проблемы не критичные. А может очень критичные. Но на Питоне же там чего-то завелось, так что разбираться никому не охота.
Прямо, так прямо: калькулятор требует определённой квалификации пользователя.
Если сложить 2+2 — это одно, а вот провести цепочку расчётов без потери точности (не выписывая данные на бумагу), даже на инженерном калькуляторе — это ещё тот цирк. В своё время этому даже специально учили.
Кстати, не знаю как сейчас, но когда я учился в ВУЗе нас учили выполнению сложных инженерных (и математических) расчётов на разных инструментах, включая и ЭВМ (как тогда предпочитали называть компы :)). И с тех пор я не считаю ни калькулятор, ни даже счёты таким уж простым устройством :). Не говоря уж про логарифмическую линейку :)
Теперь про Питон и плюсы — питон требует не меньшей квалификации, а скорее обладает более низким порогом вхождения и главное для автора статьи — не требует усилий для обеспечения вычислений, не отвлекает от самой реализации алгоритма расчета. И это для него основное, в данном случае ему нет необходимости «лезть под капот». И пусть механизм работы с памятью для автора останется скрытым — для его задачи это не важно.
А на плюсах автору вместо написания алгоритма приходится уделять довольно много внимания тому что обеспечивает его расчет и в чём автор не разбирается и не должен в принципе разбираться.
Надеюсь, что моя позиция стала более понятной.
Просто всякому овощу своё место, и что не сделаешь на питоне, то можно сделать на плюсах. Обратное же скорее не верно :)
Если сложить 2+2 — это одно, а вот провести цепочку расчётов без потери точности (не выписывая данные на бумагу), даже на инженерном калькуляторе — это ещё тот цирк. В своё время этому даже специально учили.
Кстати, не знаю как сейчас, но когда я учился в ВУЗе нас учили выполнению сложных инженерных (и математических) расчётов на разных инструментах, включая и ЭВМ (как тогда предпочитали называть компы :)). И с тех пор я не считаю ни калькулятор, ни даже счёты таким уж простым устройством :). Не говоря уж про логарифмическую линейку :)
Теперь про Питон и плюсы — питон требует не меньшей квалификации, а скорее обладает более низким порогом вхождения и главное для автора статьи — не требует усилий для обеспечения вычислений, не отвлекает от самой реализации алгоритма расчета. И это для него основное, в данном случае ему нет необходимости «лезть под капот». И пусть механизм работы с памятью для автора останется скрытым — для его задачи это не важно.
А на плюсах автору вместо написания алгоритма приходится уделять довольно много внимания тому что обеспечивает его расчет и в чём автор не разбирается и не должен в принципе разбираться.
Надеюсь, что моя позиция стала более понятной.
Просто всякому овощу своё место, и что не сделаешь на питоне, то можно сделать на плюсах. Обратное же скорее не верно :)
UFO just landed and posted this here
Все до безумия просто. Пример:
Если в расчетах потребуется найти пределы и по условиям можно применить правило Лопиталя, то оно будет применено. Нет нужды выбирать что бы применить из нескольких десятков возможных способов нахождения пределов. Тут прикол в том, что способ выбирается из условий.
В то же время, если нужно выполнить некоторые расчеты, то есть множество инструментов, которые позволяют это сделать. Зачастую инструмент выбирается исходя из трудозатрат на вычисления, в том числе (и зачастую на первом месте) человеческих. Я тут особо хочу подчеркнуть, что под инструментом для расчетов я совсем не обязательно имею в виду ЯП — это всего лишь одно из подмножеств инструментов.
Если в расчетах потребуется найти пределы и по условиям можно применить правило Лопиталя, то оно будет применено. Нет нужды выбирать что бы применить из нескольких десятков возможных способов нахождения пределов. Тут прикол в том, что способ выбирается из условий.
В то же время, если нужно выполнить некоторые расчеты, то есть множество инструментов, которые позволяют это сделать. Зачастую инструмент выбирается исходя из трудозатрат на вычисления, в том числе (и зачастую на первом месте) человеческих. Я тут особо хочу подчеркнуть, что под инструментом для расчетов я совсем не обязательно имею в виду ЯП — это всего лишь одно из подмножеств инструментов.
если этот учёный, скажем, применит какую-нибудь теорему Фубини, не проверив её условия, то этого учёного, я думаю, немножко заклюют.
На старших курсах я теоретически обосновывал один экспериментально наблюдавшийся эффект. Вообще-то экспериментаторы его и сами обосновали, но у них были странные результаты, и это неудивительно: они записали два уравнения и разложили в ряд до третьей степени, только одно разлагали по x в предположении малого x, а второе — по 1/x в предположении малого 1/x. Их работа была опубликована в приличном журнале и часто цитировалась.
На защите курсовой я имел глупость проехаться по этой статье: обоснование там ошибочно, а мы, мол, подготовили хорошее обоснование. Но заклевали не их, а меня за апломб и панибратское отношение к научным зубрам. Конечно, комиссия признала неправильность подхода «зубров» и правильность — моего, поставив «отл» за работу и пожелав успехов в публикации, но за наглый доклад влепила мне тройку: негоже прямо называть математическую ошибку химиков-экспериментаторов ошибкой, нужно было критиковать попозитивнее и попочтительнее.
UFO just landed and posted this here
А что в ней такого страшного? Члены комиссии на защите курсовой — это в первую очередь преподаватели, а не только оценщики. В идеале, задача преподавателя — научить добиваться успеха в своей области и всему что для этого требуется. Для того что бы добиться успеха нужны не только «технические» навыки непосредственно в области деятельности, но и коммуникативные, организационные — soft skills. Комиссия преподала студенту важный урок: мало сделать что-то хорошо, важно ещё грамотно это «продать» другим людям, не настроить людей против себя. Какой смысл в том чтобы прямолинейно говорить «экспериментаторы дураки — неправильно формулы записали»? Кому от этого лучше будет? Никому! Можно же конструктивно подойти, может даже пригласить их в соавторы, сказав: «давайте улучшенную версию вашей теории разработаем».
Неумение избегать профессиональных конфликтов — это тоже недостаток компетенции. Так что и с точки зрения оценки, комиссия права — не только «техническая» сторона содержания доклада имеет значение, но и «социальная», а также качество самой презентации (выступления) и прочее.
Неумение избегать профессиональных конфликтов — это тоже недостаток компетенции. Так что и с точки зрения оценки, комиссия права — не только «техническая» сторона содержания доклада имеет значение, но и «социальная», а также качество самой презентации (выступления) и прочее.
UFO just landed and posted this here
Я далее буду использовать выделения, не воспринимайте это пожалуйста как «повышение голоса», это ради акцентов.
Студент пришел защищать курсовую — значит он хочет получить обратную связь и что бы члены комиссии засвидетельствовали его навыки и дали им оценку.
Курсовая — это тренировочный мини диплом. Таким образом, комиссия, которая оценивает курсовую, делает комплексную оценку способности студента вести профессиональную деятельность. Оценивается не только способность применять навыки непосредственно связанные с курсом, но и оформление курсовой и способность решить все сопутствующие проблемы, необходимые для выполнения задачи курсовой. Социальные навыки входят в эти задачи. Тем более, что в данном случае проявились достаточно специфические «обычаи», характерные именно для академической среды. Их тоже необходимо знать и учитывать.
дать возможностьЯ согласен, и это не противоречит тому, тому определению, что я привел. Когда я написал «научить», я имел ввиду «научить, если студент проявляет соотв. интерес». О принуждении речи не было.
Студент пришел защищать курсовую — значит он хочет получить обратную связь и что бы члены комиссии засвидетельствовали его навыки и дали им оценку.
Курсовая — это тренировочный мини диплом. Таким образом, комиссия, которая оценивает курсовую, делает комплексную оценку способности студента вести профессиональную деятельность. Оценивается не только способность применять навыки непосредственно связанные с курсом, но и оформление курсовой и способность решить все сопутствующие проблемы, необходимые для выполнения задачи курсовой. Социальные навыки входят в эти задачи. Тем более, что в данном случае проявились достаточно специфические «обычаи», характерные именно для академической среды. Их тоже необходимо знать и учитывать.
Ну, питон в научных задачах тоже надо уметь готовить. Лично видел, как объявление переменной внутри цикла приводило к выжиранию памяти на совершенно тривиальной задаче.
На самом деле, если уж сравнивать, особенно на задачах, подобных описываемой, то смотреть надо не на python vs C++, а на python vs fortran. И тут уже все не очевидно.
Фортран компилируется и работает на счетных задачах не медленнее (а зачастую — и быстрее), чем C++. При этом бережет границы массивов. Срезы и всякие хитрые выборки из массивов — из коробки. Передача параметров функциям — всегда по ссылке, но объяснить компилятору, что вот-эту-вот переменную трогать не надо и если я по глупости попытаюсь в неё написать — то это точно очепятка, надавай мне по рукам — это оно уже умеет. Горы кода — тот же lapack написан на фортране, например. Но няшных штук тит «pip install что-то-там» — я не видел (хотя, может уже и есть, не знаю).
Другое дело, что современные гики уже затянули, всё что могли, из фортрана в numpy и scipy, а знание python-а в современном мире куда более конвертируемо в ненаучные области, чем знание фортрана.
На самом деле, если уж сравнивать, особенно на задачах, подобных описываемой, то смотреть надо не на python vs C++, а на python vs fortran. И тут уже все не очевидно.
Фортран компилируется и работает на счетных задачах не медленнее (а зачастую — и быстрее), чем C++. При этом бережет границы массивов. Срезы и всякие хитрые выборки из массивов — из коробки. Передача параметров функциям — всегда по ссылке, но объяснить компилятору, что вот-эту-вот переменную трогать не надо и если я по глупости попытаюсь в неё написать — то это точно очепятка, надавай мне по рукам — это оно уже умеет. Горы кода — тот же lapack написан на фортране, например. Но няшных штук тит «pip install что-то-там» — я не видел (хотя, может уже и есть, не знаю).
Другое дело, что современные гики уже затянули, всё что могли, из фортрана в numpy и scipy, а знание python-а в современном мире куда более конвертируемо в ненаучные области, чем знание фортрана.
Для него ЯП — это один из инструментов, далеко не единственный.
Он взял молоток для забивания гвоздей (хорошо не микроскоп), но бьёт ручкой и плохой именно молоток, а другой молоток совершенно случайно взял правильно и у него получилось. Зачем осиливать молоток? Чтобы забивать гвозди, иначе не получится.
Когда я был маленький, знаете какой стороной я гвозди молотком забивал? Боком, ибо правильно у меня еще руки не могли нормально забивать — все время по пальцам норовил попасть.
Если человек вырос для владения молотком, то отлично! Молодец! Но если он еще не дорос до этого, то как его можно упрекать за то, что он не умеет пользоваться молотком правильно, если он все равно забил гвоздь и объяснил почему так делают многие?
Если человек вырос для владения молотком, то отлично! Молодец! Но если он еще не дорос до этого, то как его можно упрекать за то, что он не умеет пользоваться молотком правильно, если он все равно забил гвоздь и объяснил почему так делают многие?
Эта аналогия с молотком так разрослась, что я просто обязан ответить :)
дело в том что у молотка, шуруповёрта, и отбойного молотка почему-то наличествуют деревянные ручки, на которых надпись «ручка молотка». Только у молотка это действительно ручка, за которую надо браться, вид и название предмета соответствует его интуитивно понятному назначению. Но у шуруповёрта она торчит на месте кнопки включения, а у отбойного молотка это просто декоративный элемент. И даже если всё это написано в спецификациях к этим трём чудным моделям, это всё равно запутывает людей.
дело в том что у молотка, шуруповёрта, и отбойного молотка почему-то наличествуют деревянные ручки, на которых надпись «ручка молотка». Только у молотка это действительно ручка, за которую надо браться, вид и название предмета соответствует его интуитивно понятному назначению. Но у шуруповёрта она торчит на месте кнопки включения, а у отбойного молотка это просто декоративный элемент. И даже если всё это написано в спецификациях к этим трём чудным моделям, это всё равно запутывает людей.
на которых надпись «ручка молотка»
Из тех десятков молотков, которыми работал и тех тысяч, которые видел, ни у одного не было надписи на ручке о том что это ручка. То же касается топоров, колунов, кос, вил, лопат и всего другого инструмента.
Но у шуруповёрта она торчит на месте кнопки включения, а у отбойного молотка это просто декоративный элемент.
Что на месте кнопки? У шуруповёрта и молотка это НЕ декоративный элемент, в обоих случаях ручка — это именно конструктивный элемент, предназначенный для удержания инструмента.
У меня складывается мнение что представление об окружающем мире некоторых айтишников несколько… мультипликационны.
Секундочку. Но ведь Пайтон осилили. Значит проблема не в алгоритме была, а в том, какая логика выполнения. Если написать все вычисления от руки — результат будет как у пайтона, просто медленно. А проблемы более низкоуровневых языков, что вам приходится писать далеко не то же самое, что видите у себя в тетради. Их реализация того же синтаксического сахара менее полная, и в каких-то случаях даже самые элементарные абстракции вроде «число» или «строка» выявляют свою дырявую природу. Пайтон (а точнее, тот кто написал интерпретатор) реализовал абстракцию полнее, то есть лучше. Значит и язык — лучше, если все описанные на нём объекты ведут себя лучше. Си реализует массивы по примитивной формуле ссылка+индекс — в итоге это приводит к ошибкам в доступе к памяти. Делфи реализует переполнение для индексов массивов — и не вылетает, массивы Делфи лучше сишных. К массивам Пайтона можно применять кучу функций, которые мы можем сделать с обычным набором чисел в своих мыслях — его массивы ещё лучше. Точно так, как строки, числа, и многое другое. int — это целое число, но только от сих до сих. float — число не обязательно целое, но только пока вам не нужно очень маленькое, либо слишком большое, и есть ошибка представления, и потому оно творит мелкие гадости, которые в сумме могут наворотить больших дел. Если есть язык в котором эти две базовые абстракции менее дырявы — хотя бы могут запросить для себя больше памяти, или быть выведеными без конвертации — это уже большой плюс, и я написал о том, как этот плюс помог научному исследованию.
PS Абстракции пайтона тоже имеют свой предел, и свои дыры, но их меньше чем у си и паскаля.
PS Абстракции пайтона тоже имеют свой предел, и свои дыры, но их меньше чем у си и паскаля.
А вот попробуйте GNU guile тут есть автоматическое повышение точности чисел Целые (5) > с плавающей точкой (real 5.0 ) > Дроби (ratio 10/2 ) > Точные (exact #e5.0) c длинной арифметикой и + Комплексные (5.0r + 0.0i).
Guile Manual: Numbers
Guile Manual: Numbers
И ещё: LUSH
Тоже умеет расширять численные типы и имеет кучу научных «батареек» (линейная алгебра, обработка сигналов и прочее). Эдакий фортран в скобочках.
Тоже умеет расширять численные типы и имеет кучу научных «батареек» (линейная алгебра, обработка сигналов и прочее). Эдакий фортран в скобочках.
Си реализует массивы по примитивной формуле ссылка+индекс — в итоге это приводит к ошибкам в доступе к памяти.
Далеко не это приводит к «ошибкам в доступе к памяти».
Положим вы ожидали, что на вход придёт изображение четырёхканальное, а оно пришло с тремя (без прозрачки). Аллокатор встроен куда-то глубоко в готовую функцию из библиотеки, которую вы используете. А вот работать с данными нужно вам конкретно здесь, в этой программе. Тогда вы начинаете перебирать пиксель за пикселем, и производить некие операции, скажем свёртки. При чём библиотека эта устроена так, что перевыделяет память на набор строк изображения, скажем на 3, либо на 5. В какой-то момент вы в коде продолжаете умножать до упора. А данных картинки под вашим свёрточным ядром уже нет. Какое-то время откомпиленный код перемножает случайные числа в неизвестных областях памяти, затем доходит до защищённой области и программа вываливается.
Да, безусловно, есть ошибка программиста, что не предусмотрен ввод изображений с разным количеством каналов. Но в любом языке где массив данных — это какая-никакая абстракция имитирующая реальный массив чисел, такого бы не могло случится — потому что реальные наборы чисел не включают ничего, что находится за их пределами, и ссылки на элементы должны вести себя подобно отдельному новосозданному типу — переполнятся, и всегда оставаться в нужных пределах. Даже если сам массив динамический — это никак не мешает делать поправки, пока выделяешь ему память на рантайме. Данные в таком языке всё равно были бы неправильные, что сказало бы программисту о проблеме. Но вылетать такая программа бы не стала. И никакой опасности для системы и других потоков вычислений представлять в принципе не способна. Почему-то для меня эррейтый элемент нуля не является чем-то осмысленным, а у С это будет точно такое же разыменование. Задумывались ли вы, как так то? Абстрактное понятие о масивах у человека есть, а реализации в C по сути нет. Не говоря уже о строках — это вообще для человека ясная вещь. Для С — ткой же дырявый массив слегка дырявых чаров. А если язык не стремится создавать более высокоуровневые абстракции, и с презрением отзывается о них как о синтаксическом сахаре, тогда чем он лучше кода ассемблера? (кроссплатформенность не в счёт, можно с таким же успехом написать транслятор одного ассемблера в другой, любой нестандартный (подобно тому как делают компилятор С отдельно для каждой платформы)).
К ошибкам в доступе к памяти приводит (чаще всего) неизолированность динамических массивов, которая является прямым следствием того, что массивы С — на самом деле не настоящие массивы данных — цельные объекты, а всего-лишь ссылки на 0-элемент, с прикрученным парсингом обращений в стиле массив[переменная-число]=>*(массив+переменная-число).
Да, безусловно, есть ошибка программиста, что не предусмотрен ввод изображений с разным количеством каналов. Но в любом языке где массив данных — это какая-никакая абстракция имитирующая реальный массив чисел, такого бы не могло случится — потому что реальные наборы чисел не включают ничего, что находится за их пределами, и ссылки на элементы должны вести себя подобно отдельному новосозданному типу — переполнятся, и всегда оставаться в нужных пределах. Даже если сам массив динамический — это никак не мешает делать поправки, пока выделяешь ему память на рантайме. Данные в таком языке всё равно были бы неправильные, что сказало бы программисту о проблеме. Но вылетать такая программа бы не стала. И никакой опасности для системы и других потоков вычислений представлять в принципе не способна. Почему-то для меня эррейтый элемент нуля не является чем-то осмысленным, а у С это будет точно такое же разыменование. Задумывались ли вы, как так то? Абстрактное понятие о масивах у человека есть, а реализации в 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 часов работы. И тут — питон. Приехали.
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д среде на миллиард частиц на пайтоне, было дело. И собирал данные шумовой загрязнённости в городе) Как ни странно оба названных вами примера очень близки к тем вещам которые делал я. Только одно я делал прямо пайтоном, а другое — в специализированном матпакете (без программируемых частей). У меня всё было достаточно быстро на мощном компе. Плюс, иногда программа работала где-то на фоне в течение дней, это да. Но прочитать все нужные статьи по вопросу и потом анализировать данные — это всё равно дольше. Так что время полного исследования не особо экономится.
3) Не валит. Я использю одну и ту же библиотеку из пайтона и из С++.
4) Если вы продвинутый плюсовик — ок. Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи? Есть for, else, array — вещи, которіе узнаются во многих языках и понятны. try{} catch(){}, std::bad_alloc, std::out_of_range — это есть не везде. Более того, когда вы открываете чужой код, и видите все расчёты без этих вот штук — вы не знаете что их нужно дописать. Это нифига не очевидно. (на всякий случай напоминаю, что нерабочие коды на си и делфи написал не я — я только пытался помочь разобраться людям написавшим их, почему они не заработалали (а люди, которые их писали — знают совершенно точно, что языки программирования — это ада, фортран, паскаль и сиплюсплюс, они во многом ещё электронную почту и интернет не освоили, потому что впервые столкнулись с необходимостью моделирования. Обратились они ко мне, поскольку в отличие от них я изучал один язык в школе и в университете, и это в любом случае больший опыт чем у них. К си ни их, ни нас жизнь тогда не подготовила.))
5) иногда файл повреждён, и хотя имеет правильный формат, в нём неправильное число каналов. Я сталкивался с такими картинками. Если подтягиваете из интернета картинку с расширением png — ожидаете 4 канала. Но это не всегда так, в чём я и убедился, после написания той программы.
6) Надо было использовать формат той библиотеки, которая была нужна.
Если очередной отличник не переписывает алгоритм — программа работает в разы медленнее чем нужно, поскольку отличник оптимизирует код под конкретную задачу, а создатель библиотеки его задачи не знал.
7) Я расчитывал рост нанокристалов в 3д среде на миллиард частиц на пайтоне, было дело. И собирал данные шумовой загрязнённости в городе) Как ни странно оба названных вами примера очень близки к тем вещам которые делал я. Только одно я делал прямо пайтоном, а другое — в специализированном матпакете (без программируемых частей). У меня всё было достаточно быстро на мощном компе. Плюс, иногда программа работала где-то на фоне в течение дней, это да. Но прочитать все нужные статьи по вопросу и потом анализировать данные — это всё равно дольше. Так что время полного исследования не особо экономится.
Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи?
Ну как бы для того чтобы писать на некотором языке — надо его знать.
Человек говорит о том, что пайтон ближе к математическому языку (что достаточно перевести его под необходимый синтаксис и многое будет работать). И что вы подразумеваете под знать язык? Знание синтаксиса языка, не обеспечивает умение корректного его использования. Приводя пример выше, есть массив в си — это ссылка и сдвиг, и собственно если использовать все аккуратно, то не будет никаких проблем. Но массив для программиста — это одни кейсы использования, а массив для ученого — это другая история, для них все более абстрактно и кейсов сишных массивов недостаточно. Получается, что вместо того чтобы прочитать синтаксис языка и использовать его, человеку надо знать как его использовать, знать какие могут быть ошибки-крайние случаи, и указать для своего конкретного примера решения для тех случаев, которые актуальны в его конкретной задаче. И весь рассказ о том, что на пайтоне уже много сделано, абстракция настолько высока, что массу задач можно решить просто просмотрев синтаксис и написав "как на бумаге" почти один в один задачу интерпретатору. Другое дело, что:
-если хочешь быстрее — используй методы оптимизации;
-хочешь защиту от некорректного использования — делай кучу проверок и обработок входных данных и оборачивай все в исключения и тому подобное;
И во многих случаях, проще подождать выполнения задачи, чем сделать тоже самое в языках, которые ниже по уровню абстракции или не предназначены для выполнения данного класса задач.
В плюсах точно так же, нужно только выбрать подходящую библиотеку (но на Питоне тоже нужно ее найти и выбрать).
А ближе всего к математическому языку Хаскель
А ближе всего к математическому языку Хаскель
А ближе всего к математическому языку Хаскель
К маленькой доле математики — из прикладной математики так сходу и не сказать, к чему же он близок.
А что не так в нем с прикладной математикой?
Ну вы же утверждаете, что хаскель ближе всего к математическому языку — покажите, каким образом он ближе (питона например) к написанию численных методов решения уравнений, статистическому анализу данных, ...?
Правда интересно, писал всякую мелочь на хаскеле (даже пост на хабре :) ), но реальной пользы к сожалению не увидел.
Правда интересно, писал всякую мелочь на хаскеле (даже пост на хабре :) ), но реальной пользы к сожалению не увидел.
UFO just landed and posted this here
Вот взял первый попавшийся пример со страницы hmatrix:
Чем же это лучше (ближе к математической записи), чем
? И это всё оставляя за рамками вопрос, что все упомянутые библиотеки есть и для питона, а касательно
то в питоне (и в R, например) есть далеко не один пакет, причём достаточно зрелый.
Идейно мне хаскель очень понравился, но относительно большие проекты, особенно с этим самым переопределением всяких операторов, выглядят намного менее понятно «обычных» языков.
m ?? (All, Pos $ sortIndex (m!1))Чем же это лучше (ближе к математической записи), чем
m[:, argsort(m[1])]? И это всё оставляя за рамками вопрос, что все упомянутые библиотеки есть и для питона, а касательно
если вам нужно запилить какого-нибудь Монте-Карло или что-то такое вероятностное, то был пакет с очень приятной монадой для рандома
то в питоне (и в R, например) есть далеко не один пакет, причём достаточно зрелый.
Идейно мне хаскель очень понравился, но относительно большие проекты, особенно с этим самым переопределением всяких операторов, выглядят намного менее понятно «обычных» языков.
UFO just landed and posted this here
Так вам ближе к математическому языку (а значит, и eDSL со своими операторами)
Ну «ближе к математическому языку» и «повсюду операторы $$, <|>, >|<, ?? т.п.» — это всё-таки две большие разницы.
Вы случайную человеку формулу какую-нибудь рандомную покажите, ему тоже непонятно будет.
Обычный математический язык:
aargmaxi bi
Питон:
a[argmax(b)]странно, как можно понимать первую запись и не понимать вторую (если хоть немного знаком с любым программированием).
А вот
a ?? (Pos $ maxIndex b)(написал примерно, не искал точное название функции) намного менее понятно.
UFO just landed and posted this here
В исходной записи было ещё...
Если что, это две записи разных вещей :) Первая — взятый из примера к библиотеке, второй — простой argmax.
Ну было бы a ?? (Pos (argmax b)), было бы лучше? $ — оператор из стандартной библиотеки, позволяет избежать лишних скобочек, а ?? или [] — вопрос опыта от предыдущих языков программирования, а не от математики, скорее.
Нет, не было бы существенно лучше. Вы так легко отметаете «опыт от предыдущих языков», что достаточно странно — грубо говоря, все кто хоть немного программировал на чём-нибудь знают, что обращение к массиву идёт через [] (notable exception — матлаб, но круглые скобки оттуда всё равно к "??" не ближе). Ещё какой-то непонятный «Pos» стоит.
argmax понимаю, argsort — нет. Это такая перестановка индексов, что аргумент становится отсортированным?
Сёрьзно, не понимаете? А sortIndex так прям понятнее? Абсолютно простая запись — argmax возвращает аргумент (индекс), который при подстановке в массив даёт его максимальный элемент; argsort — возвращает аргумент(ы), при подстановке в массив даёт его элементы в отсортированном виде.
Что такое m[1], m — матрица, что ли? Иначе зачем сортировать скаляр?
Посмотрите на хаскель-код, там ведь это всё тоже есть — "(m!1)".
UFO just landed and posted this here
Типобезопасность же. Негоже напрямую элементами массива индексироваться.
Ну, допустим, я-то так и догадался так как на хаскеле немного писал. Но человек, который имеет общее представление о массивах, знает что они индексируются числами. Кстати, в математике спокойно бывает запись в духе 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}'`).
UFO just landed and posted this here
Да уж, interpolate действительно выглядит красиво, особенно если учесть что это библиотека. Про named arguments — не очень понял, то есть это всегда было в хаскеле, получается?
Кстати, можете кинуть пару примеров реальных проектов на хаскеле (а то и ещё на чём-нибудь необычном типа idris), которые адекватно написаны, с использованием соответствующих фич? Такое ощущение что язык (или как минимум культура написания на нём) местами существенно поменялся с того времени, как я смотерл. В реальной работе конечно его использовать не получится — я такой код никому показать не смогу, чтобы его поняли — но просто потыкать что там да как интересно.
А про
— там всё кроме Test if k is a valid index into xs несёт какую-то полезную информацию пользователю функции?
Кстати, можете кинуть пару примеров реальных проектов на хаскеле (а то и ещё на чём-нибудь необычном типа idris), которые адекватно написаны, с использованием соответствующих фич? Такое ощущение что язык (или как минимум культура написания на нём) местами существенно поменялся с того времени, как я смотерл. В реальной работе конечно его использовать не получится — я такой код никому показать не смогу, чтобы его поняли — но просто потыкать что там да как интересно.
А про
Prelude> :doc InBounds
— там всё кроме Test if k is a valid index into xs несёт какую-то полезную информацию пользователю функции?
Вы вручную разбираете PNG-картинку, или используете для этих целей какую-нибудь библиотеку? Если вручную, то должны были как минимум ознакомиться со спецификацией PNG, а там аж целых 5 возможных вариантов каналов есть (это не считая того, что бит на канал может быть не обязательно 8).
Если используете чужую библиотеку, которая этих нюансов не учитывает, то поздравляем, библиотеку писал рукожоп и проблем там может быть куда больше.
В любом случае, если вы «подтягиваете из интернета» — то должны относиться к этим данным с повышенной осторожностью.
Если используете чужую библиотеку, которая этих нюансов не учитывает, то поздравляем, библиотеку писал рукожоп и проблем там может быть куда больше.
В любом случае, если вы «подтягиваете из интернета» — то должны относиться к этим данным с повышенной осторожностью.
Да, я использовал библиотеку человека, который такое не предусмотрел. Но он великолепно реализовал другие нужные мне вещи, потому я просто дописал кейс с другим числом каналов. Просто когда я запускал, то не ожидал таких вещей, и несколько раз программа таки завершилась с ошибкой, пока я разобрался в чём дело.
1-2) Помните, что пишется в уголовных кодексах в преамбуле?
Незнание законов государства не освобождает от ответственности.
То, что вы не знаете — и не хотите знать, что у вас происходит в ОС, крайне негативно характеризует вас как специалиста.
3) Давайте не будем спорить. Хотя бы в силу 1-2), просто примите 3) как данность.
5) О том и речь, вы физически не можете написать реализацию для открытия и преобразования всех типов файлов в ваш формат. (Число каналов, в общем, произвольно, битность каналов не фиксирована, цветовых схем куда больше дюжины, многие форматы вообще защищены патентами) Не проще ли скачать библиотеку, которая, если смогла распознать файл, ГАРАНТИРУЕТ вывод сырых данных именно в нужном вам формате? Проще.
6) Только, Богом молю, не пишите свою ОС из-за того, что шиндовс виснит!
Кстати, а как этот пункт корреспондируется с тем, что вы же голосуете за Питон, в котором всё, что сложнее завершения приложения импортируется из готовых модулей?
7) Значит, при созвучности названных действий их реальная алгоритмическая сложность несколько отличается. У шума вообще достаточно простые формулы, ибо погрешности измерения в поле таковы, что дробные части можно просто отбрасывать за ненадобностью. У воздуха, всё-таки, и формулы позаковыристее, и число веществ под 500 уходит, и проходов до 10 штук для каждой из 16 сторон света.
Про рост кристаллов не скажу, но как-то у меня сомнения закрадываются. Такое чувство, что вы приукрасили число частиц на пару-тройку порядков. Иначе бы мы рассуждали не про питон и домашние пеки под виндой, а про выделенную никсовую ноду одного из суперкомпов о 64 cuda-ускорителях или таком же числе фишек, не говоря об mpi-архитектуре самого приложения. Признаюсь честно, расчёт газового облака я только видел у препода, и только в сокращённом виде, но даже так счётчик терабайт отработанных данных завораживал. (Даже Копатель бы работал на максималках с модами без тормозов.)
А вообще, мораль статьи проста: если вы не являетесь специалистом в какой-либо сфере, и вам нужно срочно использовать нетривиальный инструмент из неё, не беритесь сами. Найдите действительно хорошего специалиста и узнайте его мнение по данному поводу. Иначе вы всё равно ничего не добьётесь, но потратите время, силы, нервы, да ещё и осмеяны на хабре будете.
Незнание законов государства не освобождает от ответственности.
То, что вы не знаете — и не хотите знать, что у вас происходит в ОС, крайне негативно характеризует вас как специалиста.
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? Ой-ой-ой, что-то совсем плохо в мире С++.
UFO just landed and posted this here
Новость оттуда же: ваша ОС НЕ упадёт, если у неё закончилась память.
Память не сожрёт, но какой-нибудь цикл с тонной итераций по крайней мере XPшку запросто мёртво вешает. Не знаю, как с этим на Linux и более современных Windows: с такими ситуациями больше особо не сталкивался. Но почему при этом файл в лог не писать тоже не особо понятно.
В дополнение к Antervis и iCpu я лишь могу добавить, что код на Си ведёт себя именно так, как и должен — если программа написана неверно, то не стоит ожидать от неё решения ваших проблем.
Ну и нельзя обойтись без самого детского аргумента о том, что на Си пишут оперрационные системы и ничего, как-то работают.
И я не спорю с тем, что возможно Си не подходит именно под вашу задачу. Но вы говорите о преимуществе одинх языков над другими в целом, а это не выдерживает никакой критики.
Ну и нельзя обойтись без самого детского аргумента о том, что на Си пишут оперрационные системы и ничего, как-то работают.
И я не спорю с тем, что возможно Си не подходит именно под вашу задачу. Но вы говорите о преимуществе одинх языков над другими в целом, а это не выдерживает никакой критики.
В аналоге Дельфи — Лазарус, есть ключи, которые включат контроль за переполнением в разных случаях, по умолчанию это не контролируется, что бы ускорить выполнение программы, что бы использовать их, надо прочесть документацию, а не быть программистом.
В других языках, я подозреваю, всё — аналогично.
ключи
{$OVERFLOWCHECKS OFF}//Проверка переполнения целых чисел отключена
{$RANGECHECKS OFF}//проверка выхода за пределы массивов и диапазонов
{$S OFF}//Проверка на переполнение стека
{$RANGECHECKS OFF}//проверка выхода за пределы массивов и диапазонов
{$S OFF}//Проверка на переполнение стека
В других языках, я подозреваю, всё — аналогично.
Зря подозреваете. В Си/С++ никакого контроля выхода за границы массивов нет. В C# и Java — есть и он неотключаемый.
Си реализует массивы по примитивной формуле ссылка+индексНо мы ведь говорим о C++, где есть std::vector, если надо. В C тоже есть аналоги.
Делфи реализует переполнение для индексов массивов — и не вылетаетВылетает, с исключением.
Если есть язык в котором эти две базовые абстракции менее дырявы — хотя бы могут запросить для себя больше памяти, или быть выведеными без конвертации — это уже большой плюсPython/C++/Delphi этого не обеспечивают непосредственно. Это обеспечивается библиотеками для длинной арифметики, которые есть везде.
написал о том, как этот плюс помог научному исследованию.Или о том, как набор принятых конвенций в Python и ваша конкретная реализация случайно привели к удачному для Вас результату. Вы не дали никаких обоснований для того, что бы утверждать что в следующий раз ситуация не поменяется и реализация на C++ заработает, а на Python провалится.
"… глазами учёного" и этим всё сказано. Вывод был предсказуем. Конечно это не языки виноваты, C++ и Pascal — языки для программистов, а не для учёных. Учёным лучше выбрать язык попроще и время на науку тратить, а не изучать ЯП по многу лет.
Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце. Тогда будет 100% гарантия, и очень неудобная система записи.
У ОС есть механизмы гарантированной записи в файл, в правильной реализации логирования вы ничего не теряете. Для повышения производительности обычно используется файловый буфер на уровне ОС и именно он может потеряться при неожиданном завершении процесса. Но если вы вручную инициируете сброс буфера на диск, то почти гарантированно ничего не потеряете.
Случайно залезть в память системы можно как из Си так и из Delphi, но это скорее верно только для старых версий Windows. Разницы в этом моменте между Delphi и Cи нет.
Вот я таких тонкостей не знал. К сожалению, принципы функционирования ОС на таком уровне не изучаются физиками и химиками, и приходится выкручиваться.
Вот наглядный пример того разного взгляда: вы, как программист, знаете как решить проблему, сбросив на диск. Я, как учёный, этого не знал (кстати, не знаю и сейчас, хотя уже поработал немного программистом), вот и имел другое виденье — как нечто, чего не хочется повторять со своим компьютером в принципе, и в страхе за свои данные.
Вот наглядный пример того разного взгляда: вы, как программист, знаете как решить проблему, сбросив на диск. Я, как учёный, этого не знал (кстати, не знаю и сейчас, хотя уже поработал немного программистом), вот и имел другое виденье — как нечто, чего не хочется повторять со своим компьютером в принципе, и в страхе за свои данные.
Я всегда думал, что ученные отличаются от людей тем, что любую вещь сначала изучают, потом проверяют изученное и только потом лезут с ней работать
То есть человек для численного решения условного дифура должен разобраться в устройстве ОС, серьёзно? Почему ж не в устройстве процессора и как он получен из песка?
UFO just landed and posted this here
К сожалению, принципы функционирования ОС на таком уровне не изучаются физиками и химиками, и приходится выкручиваться.
ваш ответ:
Я всегда думал, что ученные отличаются от людей тем, что любую вещь сначала изучают, потом проверяют изученное и только потом лезут с ней работать
Мне показалось, что отсюда и следует, что вы хотите всех учёных заставить изучать строение ОС.
UFO just landed and posted this here
Все даже проще — вывод в stderr буферизуется подстрочно. ЕМНИП, можно установить построчную буферизацию и для произвольного потока вывода.
И кстати в отладчике можно ставить условные брейкпойнты.
И кстати в отладчике можно ставить условные брейкпойнты.
И кстати в отладчике можно ставить условные брейкпойнты.
И каким будет условие? if (somewhere in the nearest future there will occur an error)
*Это не сарказм, если что, я правда не понимаю как компилятор может предвидеть рантайм ошибку и заранее начать показывать мне несколько предыдущих действий пошагово с выводом значений. Мб есть какие-то аналогичные интерпретатору оболочки, которые так и делают?
В момент краша дебаггер останавливает выполнение и можно посмотреть стек вызова и конкретное место, где произошла ошибка, откуда вызвана эта функция и т.д.
Проще надо быть.
У вас цикл? Вы примерно представляет, сколько раз он выполняется вообще? Допустим, миллион. Ок, поставили брейкпойнт на первой команде цикла с условием остановиться через миллион проходов. Упс, рантайм ошибка. Перезагрузка (если все так плохо), заново запустили, поставили с условием остановиться через полмиллиона проходов. Оно думает-думает и остановилось. Ок, значит полмиллиона отрабатывает. Сказали — остановись еще через четверть миллиона проходов.
Таким макаром локализовали (хорошо, если точно, а если нет — так хоть примерно) количество проходов цикла, после которого возникает ошибка. Теперь останавливаемся заведомо до ошибки, но близко к ней и смотрим, что у нас происходит. Не залезли ли мы где-то в чужую память или может стек переполнен.
У вас цикл? Вы примерно представляет, сколько раз он выполняется вообще? Допустим, миллион. Ок, поставили брейкпойнт на первой команде цикла с условием остановиться через миллион проходов. Упс, рантайм ошибка. Перезагрузка (если все так плохо), заново запустили, поставили с условием остановиться через полмиллиона проходов. Оно думает-думает и остановилось. Ок, значит полмиллиона отрабатывает. Сказали — остановись еще через четверть миллиона проходов.
Таким макаром локализовали (хорошо, если точно, а если нет — так хоть примерно) количество проходов цикла, после которого возникает ошибка. Теперь останавливаемся заведомо до ошибки, но близко к ней и смотрим, что у нас происходит. Не залезли ли мы где-то в чужую память или может стек переполнен.
зачем? Номер итерации — одна из переменных, значение которой в момент краша можно просто глянуть в дебаггере.
Задачи нередко запускают на много часов, дней и даже недель. Запускаешь моделирование, через двадцать часов всё падает. Отлаживаешь и обнаруживаешь, что падает-то на двадцатом часу, но причины этого падения возникли раньше, на восемнадцатом.
Могло бы быть хуже. Запускаешь на несколько недель, ничего не падает, получаешь результат. Но можно ли ему доверять? Может быть, там на восемнадцатом часу случилось прописывание памяти, оно попортило все вычисления, но программа не упала, так как прописывание проехалось только по внутренней памяти процесса.
Я прочитал ваш комментарий, и это какой то феерический поток сознания гуманитария. Давайте попробуем разобраться.
Дальше следует поток слов, которые очень сложно парсить, но насколько я понял там что-то про выделение памяти и какой питон крутой.
Если у вас коєффициент расчитывается в цикле while до значения, которое вы расчитываете, то неправильный расчёт может нагрузить компьютер хоть и формально не бесконечным, но экспоненциально раздувающимся на каждой итерации циклом, который грузанёт систему, да так что придётся перезагружать.Насколько я понял, у вас есть программа и из-за её работы вы не можете управлять компьютером? Тут проблема с самой программой, которая некоректно потребляет ресурсы системы, ну или учёные что-то наковыряли в балансировщике ядра.
Код на винде, по крайней мере, может залезть в область памяти с кодом ОС, и крашнет её.Кхм, тоесть учёные наговнокодили так что программа лезет в системную память и даже что-то там переписывает, потом учёные запустили эту программу под рутом(админом) и виноват, конечно, ц++. Гуманетарненько.
Я помню, как мы с одноклассниками нечаяно 2 компа на уроках информатики, причём не на си писали.Сразу видно будущих учёных.
Вывод в лог файл — у вас никогда не пропадали данные из документа, если он был открыт когда выдернули штепсель? Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце.Каждуют секунду(или долю секунды) вы дописываете данные в лог, это происходит автоматичеки, на уровне библиотеки логгирования, которую учёные будут использовать, и да учёные не будут писать свою библиотеку логгирования с нуля.
Касательно кодов — все три были написаны не-программистами, а учёными. Которые знают как должны работать алгоритмы, и лексику этих трёх языков.Дак чтож вы это сразу то не сказали, а я тут распинаюсь.
Дальше следует поток слов, которые очень сложно парсить, но насколько я понял там что-то про выделение памяти и какой питон крутой.
Каждуют секунду(или долю секунды) вы дописываете данные в лог, это происходит автоматичеки, на уровне библиотеки логгирования, которую учёные будут использовать, и да учёные не будут писать свою библиотеку логгирования с нуля.
Библиотека логирования, говорите? Обычно используется print :) И хорошо если только для информационного вывода, а то бывает что и основной результат вычислений выводится принтом.
Понятно, что это не отменяет простого перенаправления в файл в shell'е.
Насколько я понял, у вас есть программа и из-за её работы вы не можете управлять компьютером? Тут проблема с самой программой, которая некоректно потребляет ресурсы системы
Ну именно поэтому программу нужно было исправлять — если бы она хоть раз заработала, она сразу после этого стала бы не нужной, т.к. уже спродуцировала нужные данные.
Сразу видно будущих учёных.
imgs.xkcd.com/comics/the_difference.png
что-то про выделение памяти и какой питон крутой
Нет, про типизацию, и какой пайтон крутой. Я где-то в другом комментарии боле подробно расписал.
Если у вас коєффициент расчитывается в цикле while до значения, которое вы расчитываете, то неправильный расчёт может нагрузить компьютер хоть и формально не бесконечным, но экспоненциально раздувающимся на каждой итерации циклом, который грузанёт систему, да так что придётся перезагружать.
Один поток не может нагрузить ядро процессора больше чем на 100%. О каком "экспоненциально раздувающимся на каждой итерации цикле" речь?
Кстати, достаточно ставить программе пониженный приоритет чтобы компьютер не терял отзывчивость.
Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце
При работе с файлами независимо от языка существует команда flush, которая физически сохраняет данные на диск, достаточно вызывать после каждого write (работать будет медленнее, но для лога важнее надежность), как говорится «было бы желание».
Вам просто нужно в таких случаях вызывать flush() в конце каждой итерации, чтобы данные действительно отправились на диск и не пропали, когда завершится процесс.
UFO just landed and posted this here
Ну с си в итоге так и не разобрались, по скольку времени пожалели на это. Не могу сказать в чём конкретно проблема была, но это явно связано с сошибкой в вычислениях на том этапе.
Но, как я уже писал в комментарии, в школе на 2-ух компах уронили WindowsXP двумя разными кодами на паскале (даже не си). Потом, конечно, таких ошибок уже не допускали, но такие вещи вполне себе компилируются, сегфолты делают.
Ваш вариант с записью блоками аналогичен методу описаному как «поиск на глаз» в пункте а), по количеству необходимых падений системы. Так что принципиальная возможность всё поломать — очень даже есть.
Давно уж это было, могу только пайтоновский поискать, я его сам писал с нуля, значит должен быть в наличии где-то на старых дисках… Но я помню что первые версии все кодов отличались только синтаксисом. Т.е. просто циклы, в которых считались итерации, и в каждом блоке подряд операции. Ничего сверх-особого, никакого использования особенностей языка. Разве что в делфи визуальная часть была в родном борланде нарисовано от руки, а так всё то же самое.
Но, как я уже писал в комментарии, в школе на 2-ух компах уронили WindowsXP двумя разными кодами на паскале (даже не си). Потом, конечно, таких ошибок уже не допускали, но такие вещи вполне себе компилируются, сегфолты делают.
Ваш вариант с записью блоками аналогичен методу описаному как «поиск на глаз» в пункте а), по количеству необходимых падений системы. Так что принципиальная возможность всё поломать — очень даже есть.
Давно уж это было, могу только пайтоновский поискать, я его сам писал с нуля, значит должен быть в наличии где-то на старых дисках… Но я помню что первые версии все кодов отличались только синтаксисом. Т.е. просто циклы, в которых считались итерации, и в каждом блоке подряд операции. Ничего сверх-особого, никакого использования особенностей языка. Разве что в делфи визуальная часть была в родном борланде нарисовано от руки, а так всё то же самое.
Andrey2008, подозреваю заинтересовался бы кодом и с полпинка дал несколько мест, где написано не совсем то, что хотели :)
А что, какой паскаль-то был?
Ну, можно сделать какой-нибудь while(fork()) {}; например.
UFO just landed and posted this here
Знаете, а у меня больше всего бомбануло с комментариев, подобных вашим, а не со статьи. Ну вызвало у вас возмущение то, что автор не осилил кресты, а где причинно-следственная связь с посылом статьи и вашим негодованием?
Автор делает попытку объяснить почему в научном сообществе пользуется большей популярностью питон, нежели си или еще что-то. Но вот в комментариях его начали макать в унитаз головой, что кресты осилить не могут и тыкают пальцем подобно Нельсону из Симпсонов.
Замечу, что при этом до сих пор никто не дал ответ зачем автору вникать во множество нюансов используя кресты, когда он может с меньшими усилиями и быстрее по времени выполнить задачу используя другой ЯП?
Автор делает попытку объяснить почему в научном сообществе пользуется большей популярностью питон, нежели си или еще что-то. Но вот в комментариях его начали макать в унитаз головой, что кресты осилить не могут и тыкают пальцем подобно Нельсону из Симпсонов.
Замечу, что при этом до сих пор никто не дал ответ зачем автору вникать во множество нюансов используя кресты, когда он может с меньшими усилиями и быстрее по времени выполнить задачу используя другой ЯП?
Не люблю JS, но почему не JS? У меня вообще складывается ощущение, что ему несколько параллельно что у него внутри там упало — он продолжит считать :)
Есть мнение, что в JS 0.3 + 0.1 != 0.4. И это только самый простой пример.
Дак и в питоне 0.1+0.2 != 0.3
Вы меня пугаете) я в нём расчеты делаю. Что за фигня с типами/точностью?
Просто особенность представления чисел с плавающей точкой — десятичные дроби точно не представимы, возникает погрешность. Числа с плавающей точкой нельзя сравнивать на равенство (почти) никогда.
Да это везде так, где идет работа с плавающей точкой. Числа с плавающей точкой нельзя проверять на равенство, нужно делать как то так: abs(a-b) > 0.001
Спасибо, учту. Хотя у меня таких коллизий не возникало, не было сравнений в структуре.
Не уверен, но вроде нынче для ряда языков это почти что не актуально. Компили сами подменяют сравнение. Где-то слышал, что так, но не проверял. Хотя, стоит отметить, на проблемы со сравнением со времён VB6 не натыкался.
там всё постоянно неявно конфертируется в строки. Простой пример:
Поэтому если у вас на каком-то этапе интеграл вернул «банан» — это норма.
[1,2,11,5,6,7].sort() // вернет 1,11,2,5,6,7Поэтому если у вас на каком-то этапе интеграл вернул «банан» — это норма.
Я щас сам немного запутался. Meklon вроде как про питон говорит, а вы о JS говорите…
Пожалуй, это первый момент, с которым сталкиваются люди при расчетах с использованием типа float. В комментариях уже объяснили куда копать.
Хотите меньше сюрпризов не вникая в особенности — используйте decimal. Но я бы рекомендовал вникнуть в особенности — использование decimal не избавляет от нюансов, а просто несколько сокращает их количество (там так же есть нюансы).
Хотите меньше сюрпризов не вникая в особенности — используйте decimal. Но я бы рекомендовал вникнуть в особенности — использование decimal не избавляет от нюансов, а просто несколько сокращает их количество (там так же есть нюансы).
Может стоит выбрать инструмент изначально ориентированный на научные вычисления?
Julia, R ни чуть не менее устойчивы, но более эффективны и ближе к математике.
Julia, R ни чуть не менее устойчивы, но более эффективны и ближе к математике.
Я правильно понял, что вы использовали числа произвольной точности с плавающей точкой в питоне? Или обычный numpy?
Промахнулся с комметарием — это вопрос к автору поста, удалить не могу
Промахнулся с комметарием — это вопрос к автору поста, удалить не могу
В данный момент пытаюсь плавно перейти на Джулию, кстати. Однако есть три минуса: требует больших в сравнении с пайтон навыков работы с консолью, требует больших навыков сборки из модулей, и требует оформления даже простых команд в виде функций (иначе медленнее пайтона в разы).
Про R я стал наслышан, когда поработал программистом, как ни странно. В научной среде про него я не слыхал, соответственно тогда ещё даже не знал о его существовании.
Про R я стал наслышан, когда поработал программистом, как ни странно. В научной среде про него я не слыхал, соответственно тогда ещё даже не знал о его существовании.
Julia медленнее Python в разы? Можете показать пример кода?
Почти любой код с глобальными переменными. Если написать код в Пайтоне весь в корне, не в функциях, и то же самое сделать в Джулии — то Джулия подтормаживает серьёзно. Наверное это компилируется код на каждом запуске, вместо того чтобы один раз при первом, как когда оформлено в виде функций. Короче, не знаю почему, но дико тупит интерпретатор, если не запаковать всё в функции.
У них свои недостатки.
У julia: отсутствие полноценного комьюнити (по сравнению с промышленными языками программирования) и инструментов разработки (я пользовалься juno, до современных IDE явно не дотягивает), система сборки хуже чем в пайтоне, а по сравнению с javaским стеком технологий вообще детский сад.
R специализированный язык, та же julia язык более общего назначения.
У julia: отсутствие полноценного комьюнити (по сравнению с промышленными языками программирования) и инструментов разработки (я пользовалься juno, до современных IDE явно не дотягивает), система сборки хуже чем в пайтоне, а по сравнению с javaским стеком технологий вообще детский сад.
R специализированный язык, та же julia язык более общего назначения.
Ну пример скорее не про python, а про любой более-менее адекватный интерпретируемый язык. Тот же common lisp замечательно (пусть и не всегда быстро) работает с любыми числами и даже с обыкновенными дробями прямо из коробки.
Подозреваю, что из списка интерпретируемых языков python выбирается всё же за готовый набор библиотек.
Подозреваю, что из списка интерпретируемых языков python выбирается всё же за готовый набор библиотек.
Улыбнуло, спасибо, интересное наблюдение)
Почему бы не на (современном) Fortran?
Или Scilab/Matlab. Нравится Scilab 6.0 — быстр, вынослив и кормить не надо. А уж визуализировать графики в нём — не проблема.
У Фортрана порог вхождения намного ниже чем в C/С++, неплохая поддержка объектно-ориентированного программирования, встроенная поддержка параллельного выполнения (coarrays), практически отсутствует алиасинг и как следствие код хорошо оптимизируется компилятором. Но — это классический старый язык, без онлайн инфраструктуры модулей и библиотек (как Питон), т.е. графики, GUI и т.п. прикрутить не всегда тривиально. Для HPC, там где нет GUI и требуется высокая производительность — сложно найти более сбалансированный вариант чем Фортран. Да и самые большие модели (>миллиона loc) — глобальный климат — почти все на Фортране.
Matlab как язык ужасен, а по скорости такой же как R и питон
Matlab как питон — хорош для быстрого прототипирования, серьёзные расчёты считает неприемлемо долго.
Из своего опыта — в университете помогал с дипломом, задача из области теории потоков (математический аппарат пересекается с гидро- и термодинамикой).
Первая попытка — Matlab+Simulink, верная модель, преподаватель всё проверил и одобрил. Одна проблема — считает неприемлемо долго (на моём пк за сутки около 1%).
Вторая попытка — голый Matlab без Simulink, уже лучше, но всё равно долго.
Третья попытка — переписал весь код на C++, день-другой конечно с отладкой повозился и оптимизациями, получилось быстрее в несколько раз, но всё равно долго. Помогла аренда High-CPU instance на AWS — там всё просчиталось за ночь.
Из своего опыта — в университете помогал с дипломом, задача из области теории потоков (математический аппарат пересекается с гидро- и термодинамикой).
Первая попытка — Matlab+Simulink, верная модель, преподаватель всё проверил и одобрил. Одна проблема — считает неприемлемо долго (на моём пк за сутки около 1%).
Вторая попытка — голый Matlab без Simulink, уже лучше, но всё равно долго.
Третья попытка — переписал весь код на C++, день-другой конечно с отладкой повозился и оптимизациями, получилось быстрее в несколько раз, но всё равно долго. Помогла аренда High-CPU instance на AWS — там всё просчиталось за ночь.
Давайте начнём с того, что вы сравнили «сложность дебага» трёх совершенно разных программ:
1. Неверной программы, которая никак не показывает прогресс выполнения.
2. Неверной программы, которая чертит график в процессе выполнения. Т.е. есть прогресс, есть точка выполнения, есть номер итерации
3. Верную программу.
И сделали вывод — проще всего устранить ошибку в провильно работающей программе.
Во-вторых давайте про С++:
1. Определитесь с терминами: у вас падает ОС или приложение (и есть .core файл для linux)? Предположу, что второе.
2. Просто поймать в отладчике момент прихода сигнала от ОС — что в этом сложного (да возможно надо предварительно скомпилироваться с отладочной информацией).
3. У вас отдельным пунктом выделена ЗАДАЧА сохранить счётчик итерации в переменной — извините если это отдельная задача, то наверное действительно не стоит заниматься дебагом кода на С++.
1. Неверной программы, которая никак не показывает прогресс выполнения.
2. Неверной программы, которая чертит график в процессе выполнения. Т.е. есть прогресс, есть точка выполнения, есть номер итерации
3. Верную программу.
И сделали вывод — проще всего устранить ошибку в провильно работающей программе.
Во-вторых давайте про С++:
1. Определитесь с терминами: у вас падает ОС или приложение (и есть .core файл для linux)? Предположу, что второе.
2. Просто поймать в отладчике момент прихода сигнала от ОС — что в этом сложного (да возможно надо предварительно скомпилироваться с отладочной информацией).
3. У вас отдельным пунктом выделена ЗАДАЧА сохранить счётчик итерации в переменной — извините если это отдельная задача, то наверное действительно не стоит заниматься дебагом кода на С++.
Знаете, интересно что все программы были одинаковыми. Функции объявлены по разному, но делают с входными данными тоже самое, и выводят те же величины. Основная функция (процедура в делфи) делает одно и то же.
Когда человек пишет программу — она может с первого раза не заработать как он ожидает. Тогда он ищет где ошибки, и как правило процесс разработки начинается с неисправной программы (неверной). Бывают блокеры, бывают мелкие баги. Это не значит что программа плоха, это значит, что её дорабатывают. Поэтому мне не нравится называть программу, которая не выполняет ожидаемое, неверной.
Программа на С++ могла бы тоже вывести график, но вместо этого всё ломала. Она бы не вывела значений после критической точки, а делфи начал выводить неправильные — это само по себе полезная информация, да ещё и время на перезагрузку не тратится. Ну а Пайтон заработал не по вине разработчика — я не написал там ничего, чего не было в кодах на си и паскале. Я написал ровно то же — не импортировал никаких протекторов, не ковырялся в параметрах запуска, не лез в консоли, не писал проверок и тестов.
пункты 1-2, как мне кажется, не относятся ко всем трём языкам. А 3 — это не Задача, это этап, который должен был быть сделан, пусть это и две строчки кода.
Когда человек пишет программу — она может с первого раза не заработать как он ожидает. Тогда он ищет где ошибки, и как правило процесс разработки начинается с неисправной программы (неверной). Бывают блокеры, бывают мелкие баги. Это не значит что программа плоха, это значит, что её дорабатывают. Поэтому мне не нравится называть программу, которая не выполняет ожидаемое, неверной.
Программа на С++ могла бы тоже вывести график, но вместо этого всё ломала. Она бы не вывела значений после критической точки, а делфи начал выводить неправильные — это само по себе полезная информация, да ещё и время на перезагрузку не тратится. Ну а Пайтон заработал не по вине разработчика — я не написал там ничего, чего не было в кодах на си и паскале. Я написал ровно то же — не импортировал никаких протекторов, не ковырялся в параметрах запуска, не лез в консоли, не писал проверок и тестов.
пункты 1-2, как мне кажется, не относятся ко всем трём языкам. А 3 — это не Задача, это этап, который должен был быть сделан, пусть это и две строчки кода.
И здесь речь скорее не о дебаге, а о полной разработке, т.к. в последнем случае дебага нет. Вы сначала описали, условно говоря, бизнес-логику вашей программы, сами выражения и в каком порядке и сколько раз их расчитывать — это занимает примерно одно и то же время на всех языках. После этого ваш код на Python — уже работает, на Delphi — надо немного доработать, на С++ — надо некоторое значительное время бороться с вылазящими из под половицы драконами.
Если «происходит какая-то очень нехорошая ошибка каким-то непонятным образом связанна с памятью» и эта ошибка, например, segmentation fault, то в линуксе следует заранее включить генерацию core dump с помощью ulimit (ulimit -c unlimited) и запускать дебаггер с файлом core.
Далее смотреть backtrace, что позволит узнать, что же произошло в программе с точностью до строчки кода, в которой произошла ошибка.
Далее смотреть backtrace, что позволит узнать, что же произошло в программе с точностью до строчки кода, в которой произошла ошибка.
«Python… глазами учёного» = Волшебство интерпретатора помогает доброму питону увидеть, сколько памяти требует моё число, ...
За 6 лет то доктора получили? На защите о IEEE 754 упомянули?
За 6 лет то доктора получили? На защите о IEEE 754 упомянули?
Для ученого (* учёный == физик, химик, биолог, статистик и многие другие) этот ваш компьютер — просто очень мощный калькулятор. И учёный ищет, как быстрее посчитать, а не как написать код правильно, у него эти расчёты одноразовые (что указано в статье).
Компьютер для нормального современного ученого это ИНСТРУМЕНТ. По-моему для облегчения собственной жизни и увеличения производительности труда инструментом нужно уметь пользоваться.
Выглядит так, будто дали лопату, но не сказали какой стороной копать.
Никто не говорит, что вы должны написать клиент-серверное приложение с мобильным интерфейсом. Но вывод в файл или отрисовку уже по итогам рассчёта, а не в процессе…
Расчеты одноразовые? Да.
Единичные? Нет!
Так может научиться пользоваться?
Выглядит так, будто дали лопату, но не сказали какой стороной копать.
Никто не говорит, что вы должны написать клиент-серверное приложение с мобильным интерфейсом. Но вывод в файл или отрисовку уже по итогам рассчёта, а не в процессе…
Расчеты одноразовые? Да.
Единичные? Нет!
Так может научиться пользоваться?
Неумение учёных переводить задачу на язык машины печально, конечно же. Но, как консультант 1С я привык к тому, что люди впадают в прострацию, при перемене положений кнопок на панели инструментов. А Вы тут требуете программирования.
Мы, программисты, заточили свои мозги на программирование, и понимаем, что вместо нас никто задачу не решит. Другие люди не понимают.
Мы, программисты, заточили свои мозги на программирование, и понимаем, что вместо нас никто задачу не решит. Другие люди не понимают.
Интересная вещь — всё, чего когда либо на моей памяти касались (из области программирования) на защитах физиков, это «в чём сделана такая визуализация?» — и то, только в случае если визуализация красивая, и кто-то из комиссии тоже такой график поверхности себе захотел.
Вот это реально любопытно. Вы в статье описываете, если я верно понял, некоторый довольно впечатляющий подход к программированию. Падение — плохо, явно абсурдный график — плохо, гладкая кривая — отлично, публикуем. А отражает ли эта кривая задуманное, или просто ошибки в программе оказались менее очевидными — кто-нибудь проверял?
Конечно была масса проверок
а) после расчёта данные дали правильный спектр значений состояний при комнатной температуре
б) после расчёта конечную точку подали на вход и расчитали в обратную сторону обратный процесс, он вывел систему в исходное состояние на нужном этапе
в) момент фазового перехода (экстремум графика) сошёлся с внешней к модели теорией
т.е. проверка по характеристикам спектра, +точка верификации в экстремуме, и по сходимости к исходному состоянию. Если говорить о теории в целом — то с тех пор прошло 6 лет, и за это время численное моделирование успели повторить в независимой команде с идентичным основным графиком, а также сама модель расширилась и опубликованы новые работы подтверждающие наличие ещё одного фазового перехода (который я открыл в тот раз, анализируя данные из Пайтона, то есть это также подтверждает их правильность)
Можно было, конечно, заняться точным расчётом сходимости, когда и функция, и её производная уже известны, но это не обязательно, так как расходимость обычно сразу либо видна на глаз из-за переполнения, либо (реже) неустойчиво уводит в сторону медленно, но верно, а в таком случае невозможно вернуться из тех точек к исходному состоянию, на то она и расходимость.
а) после расчёта данные дали правильный спектр значений состояний при комнатной температуре
б) после расчёта конечную точку подали на вход и расчитали в обратную сторону обратный процесс, он вывел систему в исходное состояние на нужном этапе
в) момент фазового перехода (экстремум графика) сошёлся с внешней к модели теорией
т.е. проверка по характеристикам спектра, +точка верификации в экстремуме, и по сходимости к исходному состоянию. Если говорить о теории в целом — то с тех пор прошло 6 лет, и за это время численное моделирование успели повторить в независимой команде с идентичным основным графиком, а также сама модель расширилась и опубликованы новые работы подтверждающие наличие ещё одного фазового перехода (который я открыл в тот раз, анализируя данные из Пайтона, то есть это также подтверждает их правильность)
Можно было, конечно, заняться точным расчётом сходимости, когда и функция, и её производная уже известны, но это не обязательно, так как расходимость обычно сразу либо видна на глаз из-за переполнения, либо (реже) неустойчиво уводит в сторону медленно, но верно, а в таком случае невозможно вернуться из тех точек к исходному состоянию, на то она и расходимость.
На мой взгляд, Python в научной среде любят вот за это: github.com/cranmer/ligo-binder/blob/master/GW150914_tutorial.ipynb.
Это пример обработки данных с LIGO (Laser Interferometer Gravitational-Wave Observatory — лазерно-интерферометрическая гравитационно-волновая обсерватория, экспериментальное обнаружение гравитационных волн космического происхождения).
Это пример обработки данных с LIGO (Laser Interferometer Gravitational-Wave Observatory — лазерно-интерферометрическая гравитационно-волновая обсерватория, экспериментальное обнаружение гравитационных волн космического происхождения).
Все-таки описанные ваши проблемы не из-за специфичности задач, а из-за самой сути языков. Разработка на языках низкого уровня всегда дороже обходится по времени, и именно из-за того, что на них сложней отлаживать (и больше).
Сам пишу на C/C++ (в основном на C) и на Python для решения задач на графах. И скажу, что комбинация C и Python очень может помочь. Вдруг не слышали, но у Python есть стандартный модуль ctypes, который позволяет импортировать C-функции из библиотек. Может пригодится.
Еще вы в комментариях писал, что мол из-за программы падает ОС, но это ведь невозможно. Вы не можете вылезти в память ядра из-за того, что есть MMU. И никакая ОС не позволит вам своей программой все поломать (по крайней мере не должна). Но даже если из-за вашей программы вам приходится перезагружаться, то логировать нужно в файлы (как уже писали). Как по вашему разработчики ядер отлаживают все? Содержимое файла никуда не пропадет. Максимум не запишутся последние 4096 байт (это я на вскидку — точно, конечно, не знаю).
Сам пишу на C/C++ (в основном на C) и на Python для решения задач на графах. И скажу, что комбинация C и Python очень может помочь. Вдруг не слышали, но у Python есть стандартный модуль ctypes, который позволяет импортировать C-функции из библиотек. Может пригодится.
Еще вы в комментариях писал, что мол из-за программы падает ОС, но это ведь невозможно. Вы не можете вылезти в память ядра из-за того, что есть MMU. И никакая ОС не позволит вам своей программой все поломать (по крайней мере не должна). Но даже если из-за вашей программы вам приходится перезагружаться, то логировать нужно в файлы (как уже писали). Как по вашему разработчики ядер отлаживают все? Содержимое файла никуда не пропадет. Максимум не запишутся последние 4096 байт (это я на вскидку — точно, конечно, не знаю).
Выше уже написали про неумение пользоваться плюсовым дебагером и не буду повторяться. Главное делать правильный вывод из этой статьи. Многие комментаторы восприняли тезис «С++ это очень плохо, питон хорошо», а на самом деле выводом должно быть: «Порог вхождения в программирование на питоне намного ниже, поэтому для непрофессионального программиста он лучше, чем С++». С++, как и Delphi, является отличным языком в руках того, кто очень хорошо его знает и умеет пользоваться инструментарием. Плюсы карают тех, кто подходит к ним как дилетант. Питон поощряет дилетантов, но платить за это приходится скоростью и областью применения.
И просто от себя советую автору и всем учёным посмотреть в сторону D. Он быстр, как С++, но гораздо добрее к новичкам. Слышал много положительных отзывов от переехавших на D c питона.
И просто от себя советую автору и всем учёным посмотреть в сторону D. Он быстр, как С++, но гораздо добрее к новичкам. Слышал много положительных отзывов от переехавших на D c питона.
Спасибо. Сам я уже с тех пор написал много всякого на С# и C++ (даже до С один раз дело доходило...), но моим коллегам пригодится. Проблема в том что кроме вашего совета тут в комментариях их уже очень много. И куда смотреть неясно — D, FSharp, scheme, common lisp, Fortran, Julia, R, Guile и Lush.
Что тут выбрать из букета? Осваивать все эти вещи и изучать что где применяется? Слишком много их всё-таки. Люди выбирают в итоге то, что на слуху. Вот я могу сказать как обстоят дела в науке. Люди в возрасте до 32 лет чаще всего используют пайтон. А наслышаны про
1) Пайтон 2) Фортран 3) Джулия, а также про 4) Паскаль 5) Си, но последние 2 не используют.
Среди старшего поколения чаще пишут на Паскале, и только в последнее время начали перенимать из-за бугра Фортран. Они слышали про Пайтон и Си ещё, но предпочитают использовать то, по чему на полке лежит учебник советских времён, т.е. дед Паскаль.
Многое просто решается в Математика/Матлаб/аналогичный пакет. Для программ используют один инструмент, обычно тот, которому первому научили. Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел. Даже те кто работает/работал программистом, хоть и знают некоторые альтернативы, всё равно придерживаются максимально простых решений, когда занимаются наукой.
Что тут выбрать из букета? Осваивать все эти вещи и изучать что где применяется? Слишком много их всё-таки. Люди выбирают в итоге то, что на слуху. Вот я могу сказать как обстоят дела в науке. Люди в возрасте до 32 лет чаще всего используют пайтон. А наслышаны про
1) Пайтон 2) Фортран 3) Джулия, а также про 4) Паскаль 5) Си, но последние 2 не используют.
Среди старшего поколения чаще пишут на Паскале, и только в последнее время начали перенимать из-за бугра Фортран. Они слышали про Пайтон и Си ещё, но предпочитают использовать то, по чему на полке лежит учебник советских времён, т.е. дед Паскаль.
Многое просто решается в Математика/Матлаб/аналогичный пакет. Для программ используют один инструмент, обычно тот, которому первому научили. Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел. Даже те кто работает/работал программистом, хоть и знают некоторые альтернативы, всё равно придерживаются максимально простых решений, когда занимаются наукой.
UFO just landed and posted this here
Что тут выбрать из букета?
А для этого нужны профессиональные программисты в штате. У совсем больших лабораторий и объединений есть профессиональные программисты. Тот же CERN публикует очень качественные библиотеки. С моей колокольни выбор выглядит так:
Нужно перемолоть кучу данных с максимальной скоростью? — C, C++, D.
Нужно посчитать статистику и работать с табличными данными? — R, Julia.
Нужна символьная арифметика с выводами — Matlab.
Исследуете теорию языков программирования — Haskel.
Не хочется запариваться со всем этим — Python. Если вдруг не хватит производительности зовём суровых сишников, они вынесут нагруженные функции в натив. Многие базовые уже вынесли, поэтому проблемы скорости возникают всё реже и реже.
Матлаб для символьных вычислений, точно — не mathematica какая-нибудь?
Не совсем так:
Фортран появился в древние годы, и за время существования заматерел, большинство вычислений там сильно оптимизированы (да и язык попроще).
Нужно перемолоть кучу данных с максимальной скоростью? — Fortran, D, C++, C.
Фортран появился в древние годы, и за время существования заматерел, большинство вычислений там сильно оптимизированы (да и язык попроще).
Что тут выбрать из букета?
Видится именно гуглёжка и проба. Изначально стоит о них почитать, глянуть, что в них в принципе есть и что он из себя представляет (а то можно и какие-нибудь таблицы сравнения найти). После этого скорее всего выйдет какое-то небольшое количество языков, которое стоит пробовать в деле. В целом, думаю любой язык можно освоить на базовом уровне и понять, что в нём есть где-то за неделю (а то и меньше). Кстати, не исключено, что окажется так, что язык A удобен для задачи вида X, а язык B для задач вида Y. Почему бы этим не воспользоваться?
Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел.
Части кода можно выносить в библиотеки динамической компоновки и подключать к тем языкам, которые их поддерживают. По факту, такие библиотеки часто могут создавать компилируемые языки (но не все).
Вспомилась фраза: Программист на Фортране будет писать на Фортране на любом языке программирования.
Надеюсь, что автор в курсе, с 0 или с 1 начинаются массивы в указанных языках, иначе не совсем понятно как можно было уронить простенький алгоритм.
Python:
Нажал ctrl-s, палец съехал и добавил «d» к курсору. Вычисления идут, идут себе полчаса и потом — Бац! Нет такой переменной «var_named». В этом большая проблема питона — он может проигнорировать опечатки, или какие-то случайные ошибки, причём даже IDE не всегда их заметит.
Нажал 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ы съедают многие человеко-годы. Вот честно, Ваши коллеги поседеют, а продукт останется говном.
google: Open source CAD system.
Серьёзные CADы съедают многие человеко-годы. Вот честно, Ваши коллеги поседеют, а продукт останется говном.
В описанной ситуации можно реализовать алгоритм, например, на Mathcad, отладить и убедиться, что он работает. А потом, если требуется скорость, переносить его на С или delphi.
А почему не взяли scheme/common lisp?
Насчет отладки C++ — если программа падает с segfault'ом, то для нее скорее всего образуется core dump файл, в котором будет вся информация о том месте, где упала программа, в том числе стектрейсы и содержимое памяти. Понять итерацию цикла, на которой произошло падение, весьма просто, если есть core dump, который загружается в отладчик.
Альтернативный вариант — запустить вычисление под отладчиком непосредственно. Все более-менее нормальные отладчики при сегфолтах умеют останавливать программу в нужном месте, и дают возможность смотреть стектрейсы и состояние памяти.
Да, это сложнее, чем в языках более высокого уровня, и требует некоторых знаний в области системного программирования. Если получается сделать вычисления на чем-то более удобном, и производительность не страдает, то конечно нужно использовать высокоуровневый язык.
Насчет падения компьютера от программы которая что-то вычисляет — это ну очень странно. Современные ОС уже очень давно нельзя обвалить (при условии отсутствия багов/эксплоитов, но в этом случае это делается намеренно, а не случайно), просто так вызвав что-то из программы, запущенной с правами простого пользователя. Тем более, если это просто вычисления, которые ничего кроме функций ввода-вывода и математики не вызывают. Я могу себе представить что система может например зависнуть от недостатка памяти (в Linux это проблема), но и в этом случае есть решения, например, квотирование ресурсов для программы или более аггресивный OOM-киллер. Кроме того, никакой язык от падений такого рода не застрахует.
Альтернативный вариант — запустить вычисление под отладчиком непосредственно. Все более-менее нормальные отладчики при сегфолтах умеют останавливать программу в нужном месте, и дают возможность смотреть стектрейсы и состояние памяти.
Да, это сложнее, чем в языках более высокого уровня, и требует некоторых знаний в области системного программирования. Если получается сделать вычисления на чем-то более удобном, и производительность не страдает, то конечно нужно использовать высокоуровневый язык.
Насчет падения компьютера от программы которая что-то вычисляет — это ну очень странно. Современные ОС уже очень давно нельзя обвалить (при условии отсутствия багов/эксплоитов, но в этом случае это делается намеренно, а не случайно), просто так вызвав что-то из программы, запущенной с правами простого пользователя. Тем более, если это просто вычисления, которые ничего кроме функций ввода-вывода и математики не вызывают. Я могу себе представить что система может например зависнуть от недостатка памяти (в Linux это проблема), но и в этом случае есть решения, например, квотирование ресурсов для программы или более аггресивный OOM-киллер. Кроме того, никакой язык от падений такого рода не застрахует.
Вот видите, это ещё и какой-то не типичный баг. Выходит, правильно я тогда решил не разбираться, а переписать на Python.
Но если зависание системы — это не совсем типичный баг для плюсов на современных ОС, то всякие проблемы с доступом к памяти, либо ub — это вещь встречающаяся повсеместно. (я говорю сейчас не только об учёных, но вообще о программистах — сейчас ub можно внезапно обнаружить и в популярных библиотеках)
Но если зависание системы — это не совсем типичный баг для плюсов на современных ОС, то всякие проблемы с доступом к памяти, либо ub — это вещь встречающаяся повсеместно. (я говорю сейчас не только об учёных, но вообще о программистах — сейчас ub можно внезапно обнаружить и в популярных библиотеках)
Повторюсь: на С++ можно писать безопасный код, не обладая невероятной внимательностью и многолетним опытом. Автор, вам стоит немного поинтересоваться актуальными возможностями хотя бы стандартной библиотеки. Маленький пример в качестве вброса (нет явного выделения/освобождения памяти, есть контроль выхода за границы массива):
В подобных ситуациях проблемы случаются обычно в местах стыковки кода на С и С++, где за вас не завернули С-шный апи в объекты (не будем здесь лезть в дебри по взаимодействию с библиотеками, собранными разными компиляторами с разными настройками). И даже в этих местах стоит использовать типичный подход С++ и чувствовать себя сухо и комфортно. Например, создаем xml-документ с помощью библиотеки libxml2:
И так далее.
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);И так далее.
UFO just landed and posted this here
это та же проблема, что и с изучением программирования в вузах в целом. Если преподаватели информатики сами не программисты (а для всех не кодерских специальностей это так), они отстают от технологий лет на 30. Тот же паскаль до сих пор преподают, хотя язык уже лет 10 можно признать официально умершим. Если речь о с++, то это обычно даже не с++03.
Чета у меня бомбануло от этой статьи. Напишите, какое у вас образование (где учились) и в каком институте делаете такие расчеты. Просто чтобы знать.
Как тут уже в комментах говорили, вы не ученый, а гуманитарий. Юзайте гламурный матлаб и стройте там свои графики. Он никогда не падает, не теряет данные и имеет встроенные типы еще круче, чем в питоне. И да, там программировать не нужно. Совсем.
Потому что для программирования нужны мозги, особенно если программировать на с++. Задача начинается не с программирования, а с написания обоснования (тоже что и ТЗ в обычном мире). Почитайте на досуге, как представляются числа в компьютере и с какой точностью вообще возможно провести вычисления. Заранее определите границы эксперимента и диапазон значений. Предусмотрите вариант потери значащих разрядов или бесконечного цикла (судя по всему, именно это и произошло в вашем случае). Ошибки банальные, я бы сказал детские. Но кажутся совершенно непреодолимыми, если на них забивать. Компилятор с++ выдал вам ошибку, но вы даже не поинтересовались куда\почему у вас делась память. Делфи вам что-то посчитал, но вам лень разбираться, почему произошла потеря точности. Зато вот реклама питона на ура.
И да, сам работал до недавнего времени в науке. Не всегда задачи решаются. Попытка притянуть результат за уши выглядит смешно. Вот питон что-то посчитал (насколько точно другой вопрос) и уже бежим за медалькой. Иногда по результатам вычислений приходится писать отчет, что задача не вычислима. И надо снова сидеть за формулами, изобретая другой подход. И учится разбираться не только в своей области, но и в своих инструментах. А компьютер — это просто инструмент. Если вы его не хотите учить, то считайте по старинке — с помощью ручки и бумаги. И нечего писать, что с++ плох, просто вы х*евый кодер.
Как тут уже в комментах говорили, вы не ученый, а гуманитарий. Юзайте гламурный матлаб и стройте там свои графики. Он никогда не падает, не теряет данные и имеет встроенные типы еще круче, чем в питоне. И да, там программировать не нужно. Совсем.
Потому что для программирования нужны мозги, особенно если программировать на с++. Задача начинается не с программирования, а с написания обоснования (тоже что и ТЗ в обычном мире). Почитайте на досуге, как представляются числа в компьютере и с какой точностью вообще возможно провести вычисления. Заранее определите границы эксперимента и диапазон значений. Предусмотрите вариант потери значащих разрядов или бесконечного цикла (судя по всему, именно это и произошло в вашем случае). Ошибки банальные, я бы сказал детские. Но кажутся совершенно непреодолимыми, если на них забивать. Компилятор с++ выдал вам ошибку, но вы даже не поинтересовались куда\почему у вас делась память. Делфи вам что-то посчитал, но вам лень разбираться, почему произошла потеря точности. Зато вот реклама питона на ура.
И да, сам работал до недавнего времени в науке. Не всегда задачи решаются. Попытка притянуть результат за уши выглядит смешно. Вот питон что-то посчитал (насколько точно другой вопрос) и уже бежим за медалькой. Иногда по результатам вычислений приходится писать отчет, что задача не вычислима. И надо снова сидеть за формулами, изобретая другой подход. И учится разбираться не только в своей области, но и в своих инструментах. А компьютер — это просто инструмент. Если вы его не хотите учить, то считайте по старинке — с помощью ручки и бумаги. И нечего писать, что с++ плох, просто вы х*евый кодер.
И нечего писать, что с++ плох, просто вы х*евый кодер
Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?
Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.
Я считаю что автор поступил рационально.
Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?
Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.
Компьютер и ЯП — инструменты. Для того чтобы добиться хорошего результата инструментом, нужно уметь им пользоваться, знать принципы его работы, имеющиеся ограничения, применимость.
Автор (внимание, аналогия) отказался от шуруповёрта в пользу молотка потому что шуруповёртом было очень неудобно забивать гвозди. К тому же его корпус достаточно быстро выходил из строя, а новый экземпляр в сравнении с молотком стоил гораздо дороже. При этом, если бы он знал что шуруповёрт работает с несколько иным видом крепёжных изделий и понимал принцип его работы, возможно он смог бы добиться лучшего результата, начав использовать шурупы вместо гвоздей.
Можно ли этот его поступок считать рациональным?
Можно ли этот его поступок считать рациональным?
По-моему, вполне.
Ситуация: есть шуруповёрт, молоток и гвоздь. Гвоздь нужно забить.
Решение автора: шуруповёртом не получилось, возьмём молоток. О, нормально!
Ваше: итак, во-первых, возьмём вместо гвоздя шуруп...
Решение автора: шуруповёртом не получилось, возьмём молотокНе совсем. Скорее:
Шуруповёртом не получилось, напишем статью, почему использование шуруповёрта не подходит для работы с крепёжными изделиями.Рад что хоть попытки автором забивать гвозди шуруповёртом не оспариваются :)
Ваше: итак, во-первых, возьмём вместо гвоздя шуруп...Просто я уже давно не решал задач «забить гвоздь». А если решать задачу «закрепить изделие на стене», я вполне готов рассмотреть альтернативные технологии, сравнить их эффективность и т.п.
Причем здесь рационально он поступил или нет. Тем более, что я считаю что он поступил совсем нерационально.
Если он хочет быть ученым, то его выбор матлаб (у нас его все использовали) или вот вольфрам математика. Специально заточен под ученых, можно вводить формулы как они привыкли (что там еще в статье было) и не надо думать. Просто нажал кнопку и система все сделала сама.
А вот если он пришел на программистский портал и пытается доказывать, что с++ говно только потому что ему было лень прочитать сообщение о ошибке. Или что программа зациклилась и упала, но это не ошибкапрограммиста ученого, а просто язык программирования плохой. И ожидает, что за его громкие титулы ученого ему все будут прощать.
Если он хочет быть ученым, то его выбор матлаб (у нас его все использовали) или вот вольфрам математика. Специально заточен под ученых, можно вводить формулы как они привыкли (что там еще в статье было) и не надо думать. Просто нажал кнопку и система все сделала сама.
А вот если он пришел на программистский портал и пытается доказывать, что с++ говно только потому что ему было лень прочитать сообщение о ошибке. Или что программа зациклилась и упала, но это не ошибка
отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.лучше бы он ездить научился.
а то права купил и теперь всем рассказывает что формула 1 плоха, потому что по городу не погоняешь и передачи надо самому переключать.
а вот рено хорош, там автоматика даже думает за тебя, вообще ничего делать не надо
Просто информация для человека работавшего в науке:
а) метод стрельбы, к примеру, полагается на точное знание асимптотики функции, и должен вести счёт до попадания в небольшую окрестность этого конечного результата. Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
б) необходимая точность для гарантии сходимости выбранного численного метода расчитывается из теории, и прежде чем выделять память программно правильно, нужно заранее расчитать некоторые величины. В физике есть 3 способа оценить необходимые для такого расчёта величины: 1) теория (аналитического решения нет); 2) численное моделирование (рекурсия, см. пункт б)); и 3) эксперимент (скорость охлаждения в исследуемом процессе~10^6К/с, данных столько же, сколько у слепого котёнка). Так что, справедливо взвесив возможности, можно сказать (и даже написать отчёт) что задача неразрешима и невычислима. А можно прикинуть любую случайную длину, скажем 32 бита для начала, а уже затем увидеть где есть расходимости и поднять точность для таких «узких мест».
А то люди так много открытий потеряют… Которые ТЗ не соответствуют.
а) метод стрельбы, к примеру, полагается на точное знание асимптотики функции, и должен вести счёт до попадания в небольшую окрестность этого конечного результата. Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
б) необходимая точность для гарантии сходимости выбранного численного метода расчитывается из теории, и прежде чем выделять память программно правильно, нужно заранее расчитать некоторые величины. В физике есть 3 способа оценить необходимые для такого расчёта величины: 1) теория (аналитического решения нет); 2) численное моделирование (рекурсия, см. пункт б)); и 3) эксперимент (скорость охлаждения в исследуемом процессе~10^6К/с, данных столько же, сколько у слепого котёнка). Так что, справедливо взвесив возможности, можно сказать (и даже написать отчёт) что задача неразрешима и невычислима. А можно прикинуть любую случайную длину, скажем 32 бита для начала, а уже затем увидеть где есть расходимости и поднять точность для таких «узких мест».
А то люди так много открытий потеряют… Которые ТЗ не соответствуют.
Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
Добавить счётчик итераций, если их слишком много, значит что-то пошло не так и программу лучше остановить.
А сколько там поставить? Вот у меня был случай со стрельбой — одно значение попадает очень точно на целове, там 9.00002, что-то такое. У меня функция принимает необходимое количество знаков после запятой, и идёт по бинарному дереву вариантов производной в нуле, и такой глубины, как заданная точность. Почти сразу где-то врезается в цифру 9 и попадает в эпсилон окрестность ассимптотики. Ответ есть за 3 итерации. А чуть-чуть изменил входные данные, и уже путь до эпсилон окрестности удлинился в 10000 раз.
Если точность задана, то есть оценка в количество веток на бинарном дереве. Но если ни одно из решений не падает на асимптотику, алгоритм может подгрузить следующий знак, и там ему может больше повезти. Если бы можно было определять направление изменений в какой-то далёкой итерации, и применить аналог метода градиентного спуска, то можно было бы быстро расчитывать и контролировать наличие условия выхода. Но со сложными периодическими функциями так не выходит — от них выстреливают гармоники, которые могут сделать внезапный горб на функции, когда она уже почти прижалась к своей асимптоте. И это никак не проконтролировать, ведь теперь значение в далёкой точке может свидетельствовать о расходимости, а может и не свидетельствовать. Есть масса всяких нюансов, которые не все учитывают, и которых нет в стандартных библиотеках. Защищённый таким способом код в таких случаях может вести себя следующим образом: перебрать столько значений, сколько разрешили, и вывалиться с ответом что решение везде расходится. А незащищённый код находит сходящееся, потому что уменьшает точность, пока горб не уползёт. А время выполнения у него будет разное для разных значений — где-то медленнее, а где-то и быстрее защищённого.
Если точность задана, то есть оценка в количество веток на бинарном дереве. Но если ни одно из решений не падает на асимптотику, алгоритм может подгрузить следующий знак, и там ему может больше повезти. Если бы можно было определять направление изменений в какой-то далёкой итерации, и применить аналог метода градиентного спуска, то можно было бы быстро расчитывать и контролировать наличие условия выхода. Но со сложными периодическими функциями так не выходит — от них выстреливают гармоники, которые могут сделать внезапный горб на функции, когда она уже почти прижалась к своей асимптоте. И это никак не проконтролировать, ведь теперь значение в далёкой точке может свидетельствовать о расходимости, а может и не свидетельствовать. Есть масса всяких нюансов, которые не все учитывают, и которых нет в стандартных библиотеках. Защищённый таким способом код в таких случаях может вести себя следующим образом: перебрать столько значений, сколько разрешили, и вывалиться с ответом что решение везде расходится. А незащищённый код находит сходящееся, потому что уменьшает точность, пока горб не уползёт. А время выполнения у него будет разное для разных значений — где-то медленнее, а где-то и быстрее защищённого.
А сколько там поставить?
Да любое разумное ограничение. Например, 10000 итераций. Если вдруг окажется, что их нужно больше, можно увеличить.
Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда
Будет чёткое понимание, в каких местах алгоритма возникают проблемы со сходимостью (и временем работы). Дальше можно искать ошибки в конкретном месте или менять подход к решению. В крайнем случае можно сделать "в лоб" — убрать ограничение. Если программа не завершится — будет по крайней мере понятно, что пошло не так.
а) точного ничего в природе нет. вы должны сделать оценку вашей функции. и сравнить с точностью, с которой представляются числа в компьютере. в процессе вычислений вы должны контролировать эти величины и при расхождении немедленно прерывать цикл. иногда требуется переписать цикл, благо в с++ их несколько разновидностей.
б) именно это и есть ваша научная работа. да у вас есть научная задача, но вот как решить ее — это еще одна отдельная научная задача. (и так до бесконечности :) хотите все и сразу — так не бывает
1) численное моделирование может быть итеративным и нет необходимости сразу запускать полный расчет. сделайте несколько тестовых прогонов и посмотрите на поведение функции. при необходимости, скорректируйте программу. ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил. только гении могутпред-угодать точное значение. простым смертным приходится ковырять программу много много раз, прежде чем получить хоть какой-то результат
2) ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений. да это отдельная научная проблема. не хотите изучать компьютерные науки — ваше дело, используйте матлаб и не пишите глупых статей
кароче, вы бы у меня даже экзамен не сдали.
б) именно это и есть ваша научная работа. да у вас есть научная задача, но вот как решить ее — это еще одна отдельная научная задача. (и так до бесконечности :) хотите все и сразу — так не бывает
1) численное моделирование может быть итеративным и нет необходимости сразу запускать полный расчет. сделайте несколько тестовых прогонов и посмотрите на поведение функции. при необходимости, скорректируйте программу. ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил. только гении могут
2) ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений. да это отдельная научная проблема. не хотите изучать компьютерные науки — ваше дело, используйте матлаб и не пишите глупых статей
кароче, вы бы у меня даже экзамен не сдали.
кароче, вы бы у меня даже экзамен не сдали.
Как и вы бы у меня.
точного ничего в природе нет. вы должны сделать оценку вашей функции. и сравнить с точностью, с которой представляются числа в компьютере. в процессе вычислений вы должны контролировать эти величины и при расхождении немедленно прерывать цикл.
Есть доказанные гарантии метода. Есть определённая величина шага по сетке и по времени, которая для данного класса функций будет гарантировать сходимость к правильному решению. И есть формулы для их расчёта.
иногда требуется переписать цикл, благо в с++ их несколько разновидностей.
Которые взаимозаменяемы. Можно ещё вспомнить в каком-то из языков отдельные операнды iftrue/iffalse — такие вещи нужны если вдруг употребление именно этого слова сделает код понятнее. Но потоку как-то пофиг. Вы можете реализовать один и тот же цикл как while..do, и как repeat..until. И если потрудиться учесть наличие первого прогона и форму условия, они будут эквивалентны.
ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил.
С постоянным выводом данных это не проблема. Нет никакой разницы в методах. Вопрос в дроблении кода на части. Я раздробил так, чтобы получить график. Если бы я решил по другому, и сначала бы проверил что одна итерация отрабатывает — то я бы увидел что она работает с моими начальными условиями. Это и так понятно. С другой стороны, когда я выбрал сразу много считать, я всё равно получил информацию о том что отдельные итерации с начальными значениями на входе работают — когда в консоль начали валиться данные.
ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений.
6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима. Если говорить об области применения кода, виновника торжества, то это область где даже качественное поведение функции и значения в пределах 10% точности были прорывом. Потому что экспериментальных приборов для измерения таких вещей даже косвенным образом — не существовало. Но что касается точности модели — то вы, должно быть, не знаете, как оценивать косвенную погрешность таких вычислений.
6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима.
Для типов float нет такого понятия как знаков после запятой, у них есть мантиса и порядок числа, на больших порядках числа не то что после запятой, а и целых-то нет разрядов нет. Именно поэтому падали ракеты хранящие время с плавающей точкой и плюсующие доли секунды, однажды просто там время остановливалось. У вас вообще ничего не щёлкает, когда говорят, что точка ПЛАВАЮЩАЯ?
Особенно эпично выглядят вот такие перлы:
И обнаружить (после исправления этих двух) ещё один «протекающий»* коэффициент
То есть в формулах, вы не забываете, что надо метры на секунды умножать, а не километры на дни, а тут… ПОТЁК…
UFO just landed and posted this here
Отлично, задачу решили, вопросов нет.
Но зачем потом рассказывать что программы на C++ не работают, если проблема исключительно в знании С++?
Человеку (не программисту) нужно решить задачу. А не изучить язык программирования
Тогда зачем он взял инструмент, которым не умеет пользоваться? И вместо признания "я не смог", выводы — инструмент плохой. Мультфильм такой был, документальный, про мышонка, которому "кривые кирпичи подсунули". Один-в-один.
Человеку (не программисту)
Такому человеку не следует писать глупых статей. Он написал статью, претендуя на звание программиста на портале программистов и рассказал нам почему наш язык программирования плохой. Ему указали на его ошибки.
верификация результата в науке — обязательна
Отвечу только про верификацию. Я не верю в его результат. Я не верю в его метод расчета. И я не верю в его эксперимент. Если он так проводит научную работу, как пишет статьи — то грош цена его исследованиям и его науке!
UFO just landed and posted this here
Вот, кстати, про cython я бы хотел знать в то время. Но, правильно ли я понимаю, что для правильной оптимизации cython надо иметь опыт программирование на си-подобных языках?
Но по другим (наличие результата) — есть результат.
Да нет там никакого результата, если человек использует числа с плавающей точкой и не контролирует значения в промежуточных вычислениях. Хоть какой язык возьми, на выходе будет чистое везение, которому доверть нельзя, в принципе. Но тут на несколько бит язык отсыпал побольше везения и опа — годнота!
Что касается «значащих разрядов», так вы вообще написали чушь. Вы путаете питон (у которого таких проблем нет) и С/С++ (у которых такие проблемы есть).
А с этого места, пожалуйста, поподробнее. В питон завезли символьную арифметику?
Дадут ему инструмент какого-нибудь иного рода. Пусть дорогущую лазерную установку. Он решит, что ему лень/некогда/ещё что-то читать документацию к ней, и запустит наобум. Стоит отметить, вероятность вывести её из строя при таком подходе крайне высока, вот только интересно, как на него посмотрит руководство? ЯП — это такой же инструмент, разве только цена ошибки обычно дешевле, но это не значит, что к нему не нужно читать документацию.
Инструкции к лазеру: не лезть к внутренним контактам руками без антистатического браслета, не отключать стабилизатор напряжения, не светить в глаза. Одно предложение, три пункта. С этими правилами сломать установку или навредить людям уже очень сложно. Сбить настройки можно, но потом значит придётся калибровать, только и всего. Перекачать прибор, который всё время работает в инверсной населённости? Бред, даже если светить двумя лазерами друг в друга. Спалить высоким напряжением? С поставляемым с лазером стабилизатором и защитой от статики почти нереально. Разве что гвозди им забивать, тогда конечно, сломается.
Инструкции к С, С++, общие правила работы с памятью, описание стандартной библиотеки и буста — текст будет в очень много раз длиннее. И любое правило при несоблюдении может заставить программу работать неправильно из-за ub или вылета памяти. Воспринимать это как полноценный инструмент сложно, по скольку нет протых инструкций, с которыми можно быстро ознакомить человека, и оставить его работать, твёрдо зная, что он ничего не испортит.
Инструкции к С, С++, общие правила работы с памятью, описание стандартной библиотеки и буста — текст будет в очень много раз длиннее. И любое правило при несоблюдении может заставить программу работать неправильно из-за ub или вылета памяти. Воспринимать это как полноценный инструмент сложно, по скольку нет протых инструкций, с которыми можно быстро ознакомить человека, и оставить его работать, твёрдо зная, что он ничего не испортит.
Автор сделал неверные выводы на основе неполных данных, а значит как ученый не имеет базы определяющей причинно следственную связь.
Это отменяет его объяснение почему в научном мире питон более популярен?
Невежество порождает невежество.
В университете преподаватели, особенно, у чистых математиков, редко выходят из профессиональных программистов. Чаще всего это те же математики, которые были студентами лет 20-30 назад. Или такие же, как ТС. И как они, после всех чертыханий с устаревшим бейсиком или адой, выучили C98, так они ему и обучают своих подопечных. И я сейчас по себе сужу: когда в свет вышел C++11 у меня не приняли лабу с std::auto_ptr, потому что «надо руками память работать».
А зачем изучать C98? Зачем руками в память? А незачем. Приучи человека сразу использовать умные указатели, перемещать и ловить исключения — и код становится не сильно сложнее, чем у питона. А то, что там есть ещё указатели — пускай узнают самостоятельно. А если копнуть глубже, всякие constexpr и operator дают возможность разработчикам библиотек делать очень гибкие интерфейсы с нулевой конечной стоимостью.
А пока первокурсников заставляют printf, питон будет более популярен.
В университете преподаватели, особенно, у чистых математиков, редко выходят из профессиональных программистов. Чаще всего это те же математики, которые были студентами лет 20-30 назад. Или такие же, как ТС. И как они, после всех чертыханий с устаревшим бейсиком или адой, выучили C98, так они ему и обучают своих подопечных. И я сейчас по себе сужу: когда в свет вышел C++11 у меня не приняли лабу с std::auto_ptr, потому что «надо руками память работать».
А зачем изучать C98? Зачем руками в память? А незачем. Приучи человека сразу использовать умные указатели, перемещать и ловить исключения — и код становится не сильно сложнее, чем у питона. А то, что там есть ещё указатели — пускай узнают самостоятельно. А если копнуть глубже, всякие constexpr и operator дают возможность разработчикам библиотек делать очень гибкие интерфейсы с нулевой конечной стоимостью.
А пока первокурсников заставляют printf, питон будет более популярен.
А зачем изучать C98? Зачем руками в память?
Затем, что:
std::auto_ptr, всякие constexpr и operator
при их злоупотреблении приводят к абсолютно нечитабельному коду.
Что вы понимаете под "злоупотреблениями"? Мне вот тяжело читать код с ручным управлением памятью — я от такого попросту отвык.
Да пусть даже код какой-нибудь реализации стандартной библиотеки C++ в котором чёрт ногу сломит. В тоже время с кодом движка DOOM 3, написанном по большому счёту на «Си с классами» нет никаких проблем.
Но вообще, это всё крайности и вкусовщина. Главное, что-бы удобно было лично вам и тем с кем вы работаете.
Но вообще, это всё крайности и вкусовщина. Главное, что-бы удобно было лично вам и тем с кем вы работаете.
UFO just landed and posted this here
C и С++ изучают только программисты. Естественнонаучники (за очень редким исключением) учат программирование на Делфи, а потом всякие спецпакеты. Максимум пролог будет. Там не учат С98. Там не учат что памятью в принципе можно управлять. Тем более — что нужно. Учат так: вы придумываете правильный алгоритм, компьютер его выполняет. Учат как переписать алгоритм из головы на паскаль. В дальнейшем учат параллельно матпакеты, пакеты симуляций, численные методы (теорию) и учат моделировать на практике — могут посоветовать использовать пайтон, или делфи, но ничто не мешает использовать любой язык: код никогда не смотрят, только результат в виде графиков и фазовых портретов.
Когда я год назад начал программировать на си я внезапно узнал что а) Память вообще где-то вручную выделяют б) что этим занимается программа (раньше я думал что возня с памятью — это исключительно работа ОС) в) что это не только можно, но и нужно делать в некоторых языках г) что си — один из таких языов и д) что означают бесконечные звёздочки в коде, и что такое инкремент ссылки в принципе.
До того как мне это понадобилось с си, я спокойно программировал и моделировал 14 лет на разных языках, ни разу не сталкиваясь с необходимостью высвобождать память, работать с указателями и всё в таком роде.
Использовать умные указатели и исключения — это уже следующий уровень. На тот момент, который я описал в статье, я вообще не знал о существовании прямой работы с памятью. А программировал при этом, соответственно, 9 лет (паскаль и скриптовые языки).
Когда я год назад начал программировать на си я внезапно узнал что а) Память вообще где-то вручную выделяют б) что этим занимается программа (раньше я думал что возня с памятью — это исключительно работа ОС) в) что это не только можно, но и нужно делать в некоторых языках г) что си — один из таких языов и д) что означают бесконечные звёздочки в коде, и что такое инкремент ссылки в принципе.
До того как мне это понадобилось с си, я спокойно программировал и моделировал 14 лет на разных языках, ни разу не сталкиваясь с необходимостью высвобождать память, работать с указателями и всё в таком роде.
Использовать умные указатели и исключения — это уже следующий уровень. На тот момент, который я описал в статье, я вообще не знал о существовании прямой работы с памятью. А программировал при этом, соответственно, 9 лет (паскаль и скриптовые языки).
Я не знаю где вас учили, но на моём естественно-научном факультете сначала был курс C# (2 года). А теперь вообще идёт курс Java EE c Хадупами и всем фаршем.
Если ученый/студент/аспирант хочет занимается моделирование и численными расчетами, то уж извините, но программирование надо знать. Точка.
Не хотите программировать? Для вас есть Maple, Mathematica и т.д. И то… в этих пакетах тоже дофига нужно писать.
Если ученый/студент/аспирант хочет занимается моделирование и численными расчетами, то уж извините, но программирование надо знать. Точка.
Не хотите программировать? Для вас есть Maple, Mathematica и т.д. И то… в этих пакетах тоже дофига нужно писать.
C# точно так же язык со сборщиком мусора. Это не C++. Хадуп нужен для баз данных. Редко необходимая вещь в симуляциях. Разве что большой банк данных вытащить… Но что дальше с ними делать? Мэппить? Это разве только для статистики может пригодится, не для численых расчётов, как мне кажется.
Программирование надо знать — но совсем не обязательно знать системное и низкоуровневое программирование.
Программирование надо знать — но совсем не обязательно знать системное и низкоуровневое программирование.
Я про это и пишу. Это может показаться странным, но в этом моменте я с вами не спорю. У плюсов действительно не самая лучшая репутация, особенно, из-за старых суеверий, которые всё ещё живут в умах тех специалистов, которые столкнулись с плюсами ещё в 90-х — и не следили за языком с тех пор, даже если на нём программируют по сей день. Далеко ходить не надо, вот пример:
HenadziMatuts
Современный С++ позволяет писать библиотеки для работы с математикой так, чтобы наши чисто программистские замуты не трогали пользователей библиотек — учёных, в нашем случае. Сегодня вполне можно написать библиотеку, в которой будет синтаксис, к примеру
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)); void *d = realloc((void*)&data, sizeof(Tuple_struct)*STANDARD_RESERV_MEMORY);Я рад что С развивается, но вот направление этого развития всё ещё подчиняется идеологии минимализма (ака сделай сам) и того самого фирменного си-стиля со звёздочками (я плотно не слежу, но читал обзоры на стандарты, и по ним сложилось именно такое впечатление).
Лично я уже не так боюсь С как раньше, мне в этом помог видеокурс с растолкованием разименования, системы памяти и того, зачем вообще создали С, но я понимаю что для приблизительного понимания кода С, или С++ нужно: потратить хотя бы два месяца на разбор базы, месяц покодить, потратить ещё месяц на разбор ошибок в своём коде с книжками в руках, и только к концу 4-5 месяца начинаешь только понимать что вокруг происходит.
На Пайтоне же, порог вхождения примерно такой: умеешь упорядочить свои мысли и написать блоксхему работы желаемого кода — это уже больше необходимого чтобы взять и написать. Это очень удобно для людей, которые тратят кучу времени на другие сферы своей жизни, работая не программистами, а, скажем, учёными, которым необходимо время от времени напсать какую-то программку. Проблемы с Пайтоном у меня возникают реже не потому, что я лучше его знаю, а потому что интуитивно написанный код в нём работает гораздо чаще, т.е. надо знать минимум специфики языка, чтобы эффективно им пользоваться.
Сам я нигде не работал 3 месяца, пока изучал C# — а потом выкраивал время чтобы освоить новый прикладной пакет для вычислений, пока со всех сторон наседали проекты, которые обязан делать. Но я понимаю что в таком режиме работать может далеко не каждый, и, вспоминая старые добрые времена, понимаю что освоение Пайтона заняло у меня 2 дня. Один день — прочитать методу после пар. 2 день — написать «привет, мир», мешалку массивов, казуальную игру и смоделировать систему с динамическим хаосом. Язык реально понятен как пень. С си пришлось осваивать какие-то новые концепции памяти и так далее…
Вот правду говорят, что на изучение нового языка после первого тратишь меньше времени. Я реально после паскаля все остальные быстрее осваивал. Кроме си. Так что он, хоть уже и не пугает, но вызывает больше неприятных ассоциаций, чем пайтон (кстати, даже на джулию я больше времени в итоге потратил, чем на него).
Лично я уже не так боюсь С как раньше, мне в этом помог видеокурс с растолкованием разименования, системы памяти и того, зачем вообще создали С, но я понимаю что для приблизительного понимания кода С, или С++ нужно: потратить хотя бы два месяца на разбор базы, месяц покодить, потратить ещё месяц на разбор ошибок в своём коде с книжками в руках, и только к концу 4-5 месяца начинаешь только понимать что вокруг происходит.
На Пайтоне же, порог вхождения примерно такой: умеешь упорядочить свои мысли и написать блоксхему работы желаемого кода — это уже больше необходимого чтобы взять и написать. Это очень удобно для людей, которые тратят кучу времени на другие сферы своей жизни, работая не программистами, а, скажем, учёными, которым необходимо время от времени напсать какую-то программку. Проблемы с Пайтоном у меня возникают реже не потому, что я лучше его знаю, а потому что интуитивно написанный код в нём работает гораздо чаще, т.е. надо знать минимум специфики языка, чтобы эффективно им пользоваться.
Сам я нигде не работал 3 месяца, пока изучал C# — а потом выкраивал время чтобы освоить новый прикладной пакет для вычислений, пока со всех сторон наседали проекты, которые обязан делать. Но я понимаю что в таком режиме работать может далеко не каждый, и, вспоминая старые добрые времена, понимаю что освоение Пайтона заняло у меня 2 дня. Один день — прочитать методу после пар. 2 день — написать «привет, мир», мешалку массивов, казуальную игру и смоделировать систему с динамическим хаосом. Язык реально понятен как пень. С си пришлось осваивать какие-то новые концепции памяти и так далее…
Вот правду говорят, что на изучение нового языка после первого тратишь меньше времени. Я реально после паскаля все остальные быстрее осваивал. Кроме си. Так что он, хоть уже и не пугает, но вызывает больше неприятных ассоциаций, чем пайтон (кстати, даже на джулию я больше времени в итоге потратил, чем на него).
Что-то вы в кучу намешали Си, С++ и C#, хотя это три разных языка.
Как бы помягче? Вы ничего не знаете. Да, пожалуй так. Получилось почти даже и без мата.
Сложность современного C++ возрастает практически линейно от сложности решаемой задачи. На самом деле, беда в том, что курса о плюсах, который был бы именно по C++17, его нет. Всё тянет корень от Си, что в корне не верно. Язык ОЧЕНЬ изменился. И то, что было актуально 20 лет назад «со звёздочками», сегодня может быть напрямую вредным для работы приложения. Вместо тысячи слов, самый тупой пример. Да, это всего лишь сортировка динамического массива. Но она не критично отличается от Питона, при этом максимально выразительна и предсказуема для разработчика.
Тут же можно возразить, мол, «Hello, World!» на многих языках тривиален. Да, соглашусь. С++ не простой язык, в этом легко убедиться, если посмотреть, как сделан std::tuple. А не надо ходить и смотреть. Вы же не ходите смотреть, как в питоне сделаны кортежи. Вы ими просто пользуетесь. Вот и в плюсах просто пишите
Единственный минус, из коробки идёт небольшой функционал. Короля играет свита, а питон — ничто без его импорта. У плюсов тут всё сложнее: есть и boost, и Qt, которые совершенно меняют взгляд на мир, но об этом тоже нужно узнать и прочесть. Хотя Qt есть и под Питон, PyQt называется, так что с концепциями можете ознакомиться и в привычной для вас среде.
Ну, и, в конце концов, не врите. Вы не освоили питон за вечер. Вы его так же изучали, пусть и чуть меньше по времени ушло на базовую часть — синтаксис. Потому что, повторюсь, короля играет свита, и именно освоение каждого нового модуля требует больше всего времени.
Сложность современного 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, я не занимаюсь численными методами, потому привёл первое, что попалось при гуглении. Если выбор был не очень, что ж, тогда посыпаю пепел своими головами.
Под никсами писал мало, и оверкоммит не встречал. Наверное, потому, что он по умолчанию отключён. Но, можно очень противный вопрос? А какой гений от администрирования его включает на машинах с агрессивным использованием памяти? Мне в принципе тяжело придумать вариант, кроме виртуальных машин, когда нужно выдавать больше памяти, чем есть. А если у вас расчёты на физическом оборудовании — или на виртуальных устройствах, зачем вы делаете себе жизнь веселее с помощью предметов фаллической формы?
Вы ничего не знаете о современном C++, и именно поэтому вы были восприняты в штыки. Вы читали статьи? Очень даже сомневаюсь.
Это, безусловно, соломинка в вашем глазу: раз уж вы взялись изучать живой язык, нужно брать только свежие статьи и книги, а не перечитывать фолианты прошлого века.
Но это же бревно в наше сообщество: ведь это мы не можем выпустить толковый учебник по современным плюсам без мохровых плесневых шуб, мы не можем вытащить его на поверхность, мы не можем проконтролировать, чтобы в библиотеках были только свежие работы по нашему языку.
0xd34df00d, я не занимаюсь численными методами, потому привёл первое, что попалось при гуглении. Если выбор был не очень, что ж, тогда посыпаю пепел своими головами.
Под никсами писал мало, и оверкоммит не встречал. Наверное, потому, что он по умолчанию отключён. Но, можно очень противный вопрос? А какой гений от администрирования его включает на машинах с агрессивным использованием памяти? Мне в принципе тяжело придумать вариант, кроме виртуальных машин, когда нужно выдавать больше памяти, чем есть. А если у вас расчёты на физическом оборудовании — или на виртуальных устройствах, зачем вы делаете себе жизнь веселее с помощью предметов фаллической формы?
UFO just landed and posted this here
Наверное, потому, что он по умолчанию отключён.
Он не может быть отключен — это базовые свойства платформы. Выключение оверкоммита — есть не его отключение, а включение эмуляции допотопного поведение. По поводу того, что он «включен» по у молчанию — уже сказали.
А какой гений от администрирования его включает на машинах с агрессивным использованием памяти?
Гению вообще не нужно ничего трогать, особенно то, назначения чего он не понимает.
Мне в принципе тяжело придумать вариант, кроме виртуальных машин, когда нужно выдавать больше памяти, чем есть.
Правильно, ведь без понимания фундаментальных вещей — их и не придумать, хотя они рядом.
Первое — память не выделяется. Второе — примеры рядом.
Берём gcc, берём заполнение вектора, заполняем его на чуть больше 1 гигабайта — получаем capacity 2гигабайта и size чуть больше 1 гигабайта. Занимает программа памяти чуть больше 1гигабайта — почему?
Да что там далеко ходить. Запускаются в системе сотни процессов и тысячи потоков со стеком 8мб по дефолту. Почему всё это запускается и не жрёт десятки гигабайт памяти?
А если у вас расчёты на физическом оборудовании — или на виртуальных устройствах, зачем вы делаете себе жизнь веселее с помощью предметов фаллической формы?
Эмуляция лишь эмуляция, и даже если её включить — она особо ничего не изменит.
Как бы вам помягче сказать, вот вы рассказывали выше человеку о том, что он ничего не знает и делает выводы, вот я могу вам то же самое сообщить. Вы НИЧЕГО не знаете и делаете то же самое. Как у человека устаревшие на 5лет представления о С++, так и у вас — устаревшие лет на 30 представления о памяти.
Охлади траханье. Поведение виртуальной памяти мне известно. Мне не было известно, что никсы позволяют оверкоммит по умолчанию, без особых системных вызовов. В силу того, что
Кроме того, на плюсах оверкоммит встретить не просто, ибо оператор new для нетривиальных классов тут же производит инициализацию вызовом конструктора. А это тут же повлечёт физическое выделение памяти и, как следствие, бросок исключения. То же верно для std контейнеров, единственный способ наткнуться на оверкоммит — вызвать reserve на огромную сумму, потому что остальные тут же заполняют память.
Вероятно, потому и не встречал оверкоммит — не писал на Си-с-классами.
Под никсами писал мало, и оверкоммит не встречал.
Кроме того, на плюсах оверкоммит встретить не просто, ибо оператор new для нетривиальных классов тут же производит инициализацию вызовом конструктора. А это тут же повлечёт физическое выделение памяти и, как следствие, бросок исключения. То же верно для std контейнеров, единственный способ наткнуться на оверкоммит — вызвать reserve на огромную сумму, потому что остальные тут же заполняют память.
Вероятно, потому и не встречал оверкоммит — не писал на Си-с-классами.
Охлади траханье. Поведение виртуальной памяти мне известно.
Прохладные истории.
Мне не было известно, что никсы позволяют оверкоммит по умолчанию, без особых системных вызовов.
Опять же, такую ахинею никто, кому известно что-то о памяти — не напишет. И в очередной раз ты это подтвердил.
Кроме того, на плюсах оверкоммит встретить не просто, ибо оператор new для нетривиальных классов тут же производит инициализацию вызовом конструктора.
Очередная ахинея, которая подтверждает мои слова выше. Инициализация производится в юзерспейсе, а значит — ничего не даёт.
А это тут же повлечёт физическое выделение памяти и, как следствие, бросок исключения.
Нет, ахинея просто невероятных масштабов. Валидный пейджфолт не может НИКАК вернуть НИЧЕГО, особенно какие-то юзерспейс исключения.
То же верно для std контейнеров, единственный способ наткнуться на оверкоммит — вызвать reserve на огромную сумму, потому что остальные тут же заполняют память.
Очередной мазарм. Вы начали рассуждать о чём-то, и вам указали на полную несостоятельность ваших рассуждений. При этом — вам даже кейс дефолтный показали, где проявляется профит. Если вы не способны назвать подобный пример, если вы не способны осознать подобный пример — вы ничего не понимаете.
Особенно меня веселит «огромную сумму» — какую? На чём основаны эти глупые утверждения?
Вероятно, потому и не встречал оверкоммит — не писал на Си-с-классами.
Каждая следующую отмазка всё невероятней. Да самое использование слова «оверкоммит» — признал полной несостоятельности, ведь человек просто ретранслирует базворды, значения которых он не понимает.
Мне на секунду почудилось там лямбда выражение…
И что? Простейшая же штука.
Всё тянет корень от Си, что в корне не верно. Язык ОЧЕНЬ изменился.
Да, язык изменился, но это ничего не изменило. Он как был си — так им и остался, а значит почти вся базовая логика( именно логика языка, а не 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. Сложно, но можно. Как я уже сказал: зачем? Если для задачи достаточно контейнера вариантов, почему не воспользоваться им?
Очередной клоун.
Не позволяет. Я уже отвечал на эту ахинею. Подобное кастыляние работает сбоку, т.е. не на уровне шаблонов, описания типов аргументов и ТП.
Уровень маразма находится где-то в районе рассуждений о том, что в жс есть перегрузка функций, ведь typeof'ом можно что-то подобное накастылить.
Примеры я уже показывал, но они в очередной раз были проигнорированы.
Меня это мало волнует. Когда клоуну ответить нечего — начинаются рассуждения о том, что он что-то там много лет учил, и что-то там смотрел. Есть что ответить — отвечай, а нету — твоя клоунада меня мало волнует.
И много из себя представляешь ты, без готовой лапши? Ничего. И это ничего не меняет. Тебя не об этом спрашивали. Дак и тому же, как-то ты быстро слился на неведомый С/С++ с обсуждаемого тут «современного С++». Хотя что ещё ожидать.
Опять же, типичная шаблонная ахинея. Тебя не спрашивали о том, что можно, либо не можно написать. И что же ты слился на пых? Куда пропала та же жава? Тебе говорили о том, что никому не нужны твои рассуждения, ведь они противоречат реальности. Рантайм резиновый, и множество людей с этим живёт. Твои рассуждения в их реальности не котируются, а их реальность куда более реальна, нежели твои шаблонные лозунги.
Аргументы, такие аргументы.
Пошли очередные мазы. Всё, на что у меня нет ответа — не нужно, при этом нет ни единого обоснования подобному трёпу.
Клоуны настолько неадекватны, что противоречат реалиям того же языка. Клоун орёт «всё есть», а люди пилят концепты. Вот ведь идиоты. Клоун орёт, что «обходить таппл не нужно», но в стандарт добавляют хелперы, которые реализуются через tuple expansion, что и есть его обход.
И да, таппл отличается от массива только потому, что это убогий кастыль. Если бы в языке была нормальная рефлексия, то он бы ничем от массива не отличался. Налицо полный неадекват и непонимание базовых вещей.
И? Я где-то утверждал обратное?
Неможно. В рамках контексте предполагается решение «без магии», а не любое решения.
Распакуй таппл в набор параметров. Типичный кейс, который ввели в стандарт.
Реализуй любую операцию поверх таппла — ничего не сможешь, кроме уже реализованного сравнения.
Я нихрена не понимаю, что за «контейнера вариантов» и каким боком он тут взялся, но всё же.
Вариант — это рантайм кастыльня. Т.е. мы видим типичное проявление того, о чём я говорил. Пациент, который со мной пытается спорить — сам же признаёт, что статический интерфейс говно и надо использовать динамический интерфейс, пусть и с убогой статической обёрткой.
Массив вариантов — такое же динамическое решение, и это очередной слив.
К тому же, это очередной слив ещё и тем, ведь вариант это так же 17 кресты, а значит мы автоматически множим предыдущие на ноль и это ничего не меняет.
Да и куда делся any?
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-кастыли — не решение.
С таким успехом — можно всё что угодно записать в сахар. Молоток то же сахар, ведь задолбить гвоздь можно и микроскопом, дальше что? А ничего. Это просто полный неадекват.
Есть решения, а есть костыли. Если раньше что-то решалось костылями, а теперь даётся нормальное решение, то оно не становится сахаром, тем более, что оно намного мощнее костылей.
Ок. Не могли бы вы предложить ваш вариант реализации кортежа — убийцы нынешнего?
Кортежи — это про рефлексию, а не про концепты. Кстати, рефлексия тоже сахар?
И да, очередной идиотский вопрос. Хотя о чём я говорю, ведь ваши ответы — типичный заспам неадекватом. Я говорю о том, что в крестах нет средств для реализации вменяемых статических интерфейсов, а мне несут какую-то ахинею про „а где ваш вариант?“. Шаблон сломался? Это такой же полный неадекват.
Если хотите, чтобы я пояснил — почему кортежи в текущих реалиях нельзя реализовать нормально, то я объясню. Точно так же — я могу пояснить и по поводу того, как оно должно выглядеть.
Точно так же — я могу пояснить и по поводу того, как оно должно выглядеть.
Валяйте. А то весь этот спор только у вас в голове, похоже
Естественно, С++ полезен, но и с асм«ом жить можно. Дальше что? И да, концепты не сахар, а sfinae-кастыли — не решение.
Разница между С++ и ассемблером очень большая.
Если говорить про концепты, то они проще пишутся (но это важно при написании сложного шаблонного класса) и упрощает ошибки компиляции (лично я примерно за 2 года уже научился их понимать :), серьезные разработчики — я уверен, тоже).
Кортежи — это про рефлексию, а не про концепты. Кстати, рефлексия тоже сахар?
Да, про рефлексию. Нет, рефлексия не сахар, потому что в стандарте способов обойтись без неё нет (так как нужно патчить компилятор).
И я абсолютно серьезно спрашиваю про вашу версию. Сделать динамический кортеж — без проблем, это будет что-то вроде std::vector<std::any> (или void ** и std::type_index). Это дешево, но не 0. А вот более красивый статический интерфейс для кортежа без костылей вида "пропихнем в ядро языка", как в питоне, я не знаю. То что есть сейчас, можно реализовать в рамках переносимой библиотеки, что плюс.
Разница между С++ и ассемблером очень большая.
В данном случае это не принципиально. Разница между написанием даже на готовых примитивах пародии на концепты и использование концептов — такая же «очень большая».
лично я примерно за 2 года уже научился их понимать :), серьезные разработчики — я уверен, тоже
Это не особо продуктивно. Существует очень много людей — их подавляющие большинство, которые не занимают написанием абстракций, интерфейсов, а просто используют готовые. Они мало знакомы с проблемами, которые возникают. С ограничениями, которые не позволяют что-то реализовать(приемлемо) и прочее. Научиться понимать пару знакомых паттернов и понимать ошибки — это две большие разницы.
Ну будет у вас ошибка вида «не найдено» — дальше что? Что она даёт? Что из неё следует? Ничего. Как максимум — вы получите контекст, но это мало что даст.
А если вы пользователь интерфейса? Эти ошибки полностью бесполезны.
И я абсолютно серьезно спрашиваю про вашу версию.
«Вменяемая» версия невозможна в рамках текущих возможностей языка.
А вот более красивый статический интерфейс для кортежа без костылей вида «пропихнем в ядро языка»
Очень просто. Тут вылезают все проблемы, ведь почти всё в с++ — убогие костыли.
Нету рефлексии нету — struct {type;type;}, да ладно там рефлексия — нельзя генерировать идентификаторы. Да что там идентификаторы — вообще ничего нельзя, кроме подстановки типов/значений базовых типов. Какое же метапрограммирование может быть без этих фишек?
А далее, мы видим очередной уродство — аргпаки. Вместо того, чтобы реализовать их на базе рефлексии, как некий компил-тайм итерируемые объекты, вместо того, чтобы добавить к типу метаинформацию — мы имеем костыли, и убогую распаковку в перечисление через запятую.
Это попытались хоть как-то решить в folding expressions, но оно не умеет в типы, а так же не умеет в ;. Но в любом случае — это уже хоть какая-то кодогенерация, а не gnuc 80 годов.
А далее мы имеем язык 80годов, который просто не предназначен для подобного. Да, constexpr — это начало пути к нормальному языку, но всё же. Это лишь костыль.
За примерами далеко ходить не нужно — мы не можем написать цикл по компил-тайм списку. Хотя этому ничего не мешает, но мы всё равно обременены ограничениями рантайм языка.
for() {v;}, где v — есть переменные разных типов в разных итерациях цикла.
Сейчас мы должны генерировать каждое тело подобного цикла отдельно. Типично — через функции, сейчас лямбды. Большинство любят лямбды не потому, что они такие полезные, а потом, что этот костыль позволяет обходить подобный кейс.
for() {[]{v;}}
В этом и фишка, что по сути — в компилтайме С++ может обладать динамикой, причём не уровня костылей, а уровня языка. Компилтайм части языка — не нужна та статика уровня рантайма. И мы получаем «питон», а не экспортируем ограничения рантайма на компилтайм.
Поэтому да, нужно пропихивать в «ядро языка», только не кортежи, а функционал, который и позволить реализовать этот красивый интерфейс.
Как будет время — я опишу подробно две эти темы. Что и почему в языке является костылём, и как( примерно) это должно( по моим представлениям) выглядеть.
Это попытались хоть как-то решить в folding expressions, но оно не умеет в типы, а так же не умеет в ;
умеет
Ну что за клоунада? Где тут типы и где тут ;?
Для справки, с каких пор args стал типами? Да и тому, что писал этот хелворд нужно срочно букварь перечитать на тему того же pf.
Для справки, с каких пор args стал типами? Да и тому, что писал этот хелворд нужно срочно букварь перечитать на тему того же pf.
Где тут типы и где тут ;?
я продемонстрировал обход вариадик пака функцией буквально в одну строчку. Это и есть ";". По аналогии можно обходить и типы. Это буквально доказательство того, что
Это попытались хоть как-то решить в folding expressions, но ононеумеет в типы, а так женеумеет в ;
Ты мне; покажи, а не клоунаду убогую.
Я даже поясню: в твоей пасте разделителем используется ,(запятая), а не точка с запятой(;).
Второе, твоя глупая попытка не генерирует список типов, а то, что ты впихнул туда тип — ничего не меняет, т.к. в результате всё равно нет списка типов.
И самое интересное, почему заигнорил часть моего комментария про букварь?
Я даже поясню: в твоей пасте разделителем используется ,(запятая), а не точка с запятой(;).
Второе, твоя глупая попытка не генерирует список типов, а то, что ты впихнул туда тип — ничего не меняет, т.к. в результате всё равно нет списка типов.
И самое интересное, почему заигнорил часть моего комментария про букварь?
Люди живут без них и ничего.
А потом жалуются на всякие взломы, падения, BSODы и прочие "если бы программисты строили дома". Не делайте так.
А потом жалуются на всякие взломы, падения, BSODы и прочие «если бы программисты строили дома».
Ну на «современных С++» ничего нет(по крайне мере я об этом не знаю, но вы можете мне такие примеры показать), поэтому не с чем сравнивать. А вот С/С++ на который была попытка съехать выше — там бсоды, падения, взломы и чего только нет.
В любом случае — этот разговор бессмысленный, ведь дискутировать тут попросту не с кем, либо они до сих пор сюда не явились. Всё сводится к простым шаблонным фразочкам, обвинениями в «пхпизме» и прочий зелёный фанатичный бред.
Люди не хотят ничего слушать, не хотят пытаться понять то, что им говорят. Они кидаются ярлыками и обвиняют тебя в том, что сами придумали. Основную причину я уже называл — люди фанатичны по своей природе, и они попросту не могут поверить в то, что можно критиковать то, что используешься.
Критикуешь С++ — пхпист, ведь ты на самом деле не критикуешь, а выгораживаешь своё пхп. Каждый, кто отвечал мне — руководствовался этим. И как я уже говорил, да — в большинстве случаев это работает, ведь привычные людям оппоненты являются такими же фанатиками.
Приходишь в тему с тегом С++ и критикуешь к ресты — фанатики тебя минусуют, ведь ты просто не осилил и на самом деле пхпист. Приходишь в тему с тегом раст и критикуешь раст, защищая кресты — ты крестовый фанатик и не осилил раст.
За этим так интересно наблюдать. Кем же я буду в следующий раз.
Приходишь в тему с тегом С++ и критикуешь к ресты — фанатики тебя минусуют, ведь ты просто не осилил и на самом деле пхпист. Приходишь в тему с тегом раст и критикуешь раст, защищая кресты — ты крестовый фанатик и не осилил раст.
заходишь на хабр потроллить и побуггуртить — минусуют, сволочи эдакие!
UFO just landed and posted this here
UFO just landed and posted this here
Да уж, вот был бы язык с нормальным тайпчекером — но с такой же универсальностью и количеством библиотек, как питон — думаю многие бы стали пользоваться.
UFO just landed and posted this here
Ясное дело, вы же им пользуетесь :) Странно, если бы мучались с языком, где вам не хватает библиотек. Но вы же не будете спорить, что их существенно меньше, чем в R/Python? Нет официальных биндингов даже для очень популярных библиотек — остаётся надеятся на то, что создатели сторонних биндингов продолжат их поддерживать. Для несколько менее популярных, а тем более узкоспециализированных — нет вообще ничего. Ну и ещё библиотеки, которые вроде есть, но существенно ниже покрытием и размером комьюнити.
UFO just landed and posted this here
быстрый статистический анализ данных я бы набросал на R
Ну вот, а говорите хаскеля хватает :)
Есть вообще хороший регулярно обновляемый пост.
Увы, он навевает только грусть, если честно (хотя немного радостно видеть, что некоторые моменты всё-таки доделали с тех пор, как я пытался им пользоваться). Как после «Data science Rating: Immature», «Numerical programming Rating: Immature», «Machine learning Rating: Immature», «Computer Vision Rating: Immature», «Debugging Rating: Immature», «Cross-platform support Rating: Immature», «IDE support Rating: Immature» можно вообще считать хаскель языком, которым могут массово пользоваться учёные (например)? И это страница именно про haskell, то есть если там и смещены оценки в какую-то сторону, то скорее в оптимизм.
Собственно, у python в аналогичном списке почти нигде не было бы «best in class», но зато mature (good enough) практически во всех сферах.
P.S.: не фупм случайно, какого года?
C и С++ изучают только программисты. Естественнонаучники (за очень редким исключением) учат программирование на ДелфиОткуда такие данные? Скорее наоборот, Делфи — это редкость для преподавания на факультетах физики/математики/химии/биологии, как в б. СССР так и на Западе. Даже на пике своей популярности, Делфи не слишком проник в курсы для студентов-естественников, а сейчас-то, наверное, вообще почти нигде и не преподают его. Рискну предположить, что на сегодня в топ популярности входят: Python, C(++), Java, C#, Matlab, Mathematica/Maple, R, Haskell, LabVIEW, fortran, ML, go, JavaScript, Perl, Pascal. Дельфи, мне кажется, преподается реже любого из выше перечисленных.
Python, Matlab, Mathematica/Maple и ещё пролог и маткад могут показывать физикам, вместе с пакетами типа ansys и comsol. Но только в курсах от физиков-физикам. А если говорить про курсы от программистов-физикам (главные курсы по программированию, с наибольшим числом часов, и на которые опираются все последующие) — обычно начинаются с делфи. Я знаю один вуз, где джава (и он мне не нравится — там студенты всё равно даже на парах не появляются, все программистами работают, вместо того чтобы учиться основному предмету).
обычно начинаются с делфи3 примера известных вузов пожалуйста.
Назову один, который знаю: Харьковский Аэрокосмический Университет.
А на какой кафедре? Я вот открываю вопросы по теме «Об’єктно-оріентоване програмування» и в списке литературы вижу только книги по C++:
Нашел вопросы тут: www.khai.edu/uk/site/maibutnim-magistram-i-spe.html
Круглински Д., Уингоу С., Шеферд Дж. Программирование на Microsoft Visual C++ для профессионалов
...
Нашел вопросы тут: www.khai.edu/uk/site/maibutnim-magistram-i-spe.html
Так вы же смотрите компьютерные науки) Откройте программу «программирования» для физиков или химиков. И желательно не в техническом, а в классическом университете (там относительное количество преподавателей-программистов ниже).
я смотрю то, что первое нагуглилось. Если Вы знаете, где делфи — дайте ссылку. Бремя доказательства…
Вот я открываю самый что ни на есть классический Киевский университет Шевченка, факультет физики, общий курс для всего потока 1го курса — C:
http://docs.phys.univ.kiev.ua/pdfs/HND_1k.pdf
Лектор — Усенко Костянтин Володимирович, с кафедры теор. физики вообще.
http://docs.phys.univ.kiev.ua/pdfs/HND_1k.pdf
програмування мовою C
Лектор — Усенко Костянтин Володимирович, с кафедры теор. физики вообще.
Программу не нахожу, но поднял профиль своей специальности, там говорится следующее:
Как видно, там даже и работа с делфи не указана — прикладные пакеты.
Ну там и 152 специальность есть. Может это для них? Приборостроение, как бы. Там С пригодится точно.
А вот курс для физиков, с того же сайта, на котором вы смотрели: theory.phys.univ.kiev.ua/uk/system/files/users/shared/usenko-progr.pdf
Начинается с паскаля. (в теоретической программе про методы интерполяции, решения иффуров и т.п. — а ссылку я дал на прикреплённый к курсу учебник)
Выдержка из документа
Это всё, что там хоть как-то связано с программированием.
програмні результати навчання:
…
Мати навички роботи із сучасною обчислюівальною технікою, вміти використовувати стандартні пакети прикладних програм і розробляти програмне забезпечення на рівні, достатньому для реалізації чисельних методів розв'язування фізичних задач, комп'ютерного моделювання найпростіших фізичних явищ і процесів, виконання обчислювальних експериментів
Это всё, что там хоть как-то связано с программированием.
Как видно, там даже и работа с делфи не указана — прикладные пакеты.
факультет физики, общий курс для всего потока 1го курса — C:
Ну там и 152 специальность есть. Может это для них? Приборостроение, как бы. Там С пригодится точно.
А вот курс для физиков, с того же сайта, на котором вы смотрели: theory.phys.univ.kiev.ua/uk/system/files/users/shared/usenko-progr.pdf
Начинается с паскаля. (в теоретической программе про методы интерполяции, решения иффуров и т.п. — а ссылку я дал на прикреплённый к курсу учебник)
Ну там и 152 специальность есть. Может это для них?Нет, это для всех физиков потока вообще, разных специальностей, в т.ч. теоретическая физика, молекулярная физика, физика металлов и т.д.
вот курс для физиков, с того же сайта, на котором вы смотрели:В приведенном вами учебнике идёт сравнение разных языков, в т.ч. краткая историческая справка. Где-то идут примеры сразу на 3х языках: C++, Pascal, Maple. Но основным языком преподавания программирования там идёт именно C(++). Но Delphi нет вообще нигде. Pascal != Delphi, в контексте математики и основ программирования это важно. Pascal имеет историческую ценность и потому целесообразен для сравнения и понимания возможных различий в архитектурах языков для студентов классического университета, для расширения кругозора. Delphi же для этих целей не нужен.
Нет, это для всех физиков потока вообще, разных специальностей, в т.ч. теоретическая физика, молекулярная физика, физика металлов и т.д.
То ли лыжи не едут… То ли я чего-то не понимаю. Вот курс программирования на том же самом сайте, его содержимое:
theory.phys.univ.kiev.ua/uk/courses/programuvannia-ta-matematychne-modeliuvannia
Здесь лекции про математику методов, не про особенности конкретных языков.
Это во-первых. А во-вторых, таких специальностей не припоминаю.
Pascal имеет историческую ценность и потому целесообразен для сравнения и понимания возможных различий в архитектурах языков для студентов классического университета, для расширения кругозора. Delphi же для этих целей не нужен.
В прогах типа делфи и лазаря есть элементы интерфейса. Ты скачал пакет для разработки, и всё — есть кнопки, поля ввода и т.п. Можно и интерфейсы делать, и с ООП на примере таких объектов разбираться удобно.
В с, например, пока дело до визуализаций дойдёт, ещё возятся очень долго, как правило. Потому что сразу требуется понимание библиотек, линковки, и всего такого прочего. А в обучении быстрый видимый результат — это то что надо.
Но Delphi нет вообще нигде
Ну это 100% неверно, т.к. я обучался именно Делфи. Как и двое из моих бывших научных руководителей. И вообще говоря, неважно, что за язык. Надо понимать что то что называется курсом по программированию для научных специальностей — это на самом деле курс по математике численных расчётов и обзор методов моделирования. Который для удобства делается на каком-то из языков программирования. Штуки об устройстве языка/компьютера/ОС не изучаются. Ручная работа с памятью, ммю и прошивка плат не изучаются. Написать язык программирования, компилятор или ОС не требуют. Клиент серверных приложений и баз данных тоже. Парадигмы программирования не изучаются, равно как и патерны и методы, и форматирование кода. Не изучается работа на разных ОС и работа в разных языках, не изучаются их особенности. Не изучаются оптимизации и теория алгоритмов. Линковщик и разные компиляторы — это вообще фантастика для студента-не-программиста. Это всё изучают в курсах программирования для IT специальностей. Для физиков в курс программирования входит — сначала показать как создать проект, поле вывода и синтаксис объявления функции, события, переменной. Далее сразу сходимость, шаги, слау, интегрирование, интерполяция, аппроксимация, диффуры, распространение тепла/частиц, хаотические системы (последние пункты уже относятся к курсам моделирования и матфизики, но по сути являются плавным продолжением программирования). Нет таких курсов, на которых изучали бы всё то, что кажется самоочевидным любому третьекурснику-программисту. Просто учат использовать свободу написания алгоритма самому. И программирование, для большинства научных задач эту область и не покидает.
Здесь лекции про математику методов, не про особенности конкретных языков.Так и есть, курс называется «математическое моделирование» и основная цель — не обучить конкретно С. Тем не менее фактически преподавание идёт на примере С(++).
таких специальностей не припоминаюКаких таких? «Теоретическая физика», «Молекулярная физика»? Ну зайдите на сайт киевского физ-фака и посмотрите список кафедр.
В прогах типа делфи и лазаря есть элементы интерфейсаВы посмотрите какие цели указаны в курсе. Это как раз пример «старой школы», считается что физиков не нужно учить программированию интерфейсов, вообще. Все примеры консольные.
ООП на примере таких объектов разбираться удобноЭто отдельная тема, но в случае физ-фака ООП чуть-чуть разбирают на примере C++.
требуется понимание библиотек, линковки, и всего такого прочегоне для учёных, не в случае курса, который читает Усенко.
в обучении быстрый видимый результат — это то что надо.Достаточно консольного ввода-вывода.
>Но Delphi нет вообще нигдеречь только о курсе Усенко шла — в нём нет Дельфи вообще.
Ну это 100% неверно, т.к. я обучался именно Делфи.
неважно, что за языкЭто не имеет отношения к нашей дискуссии. Я не тянул Вас за язык и не говорил:
Естественнонаучники (за очень редким исключением) учат программирование на ДелфиПовторюсь: это ерунда. Может быть Вы и изучали дельфи, но это скорее странное исключение. Естественнонаучникам в западном мире и даже в б. СССР почти не преподают сегодня дельфи, и раньше тоже не особо преподавали. Точно так же как и в вашем посте с задачей дифференцииорования Вы взяли свой нехарактерный опыт и обобщили на «всех Естественнонаучников».
Для физиков в курс программирования входитРечь была не об этом. Тут я бы с Вами не спорил, хотя и добавил бы, что это устаревший подход. Сегодня к этому всему добавляют и обучение best programming practices тоже.
-есть специализации, есть специальности. Для первых есть спецкурсы, для вторых — представления министерства, о том, что должен знать физик.
-я бы вообще не учил физиков, что существует консольный способ взаимодействия с системой и с программой. Это достаточно сильно отталкивает от программирования, я это понял очень хорошо, когда навозился с ssh
-первая строчка в первой программе на с++ должна содержать импорт (потому что он без этого не можетв космос в вывод текста «привет мир»). Вам придётся сразу объяснять человеку принципы компоновки, системные пути и кратко про анализатор в компиляторе, если только не хотите, чтобы такие строчки писались бездумно вначале каждой программы.
Во-первых.
Про задачу. Я не обобщал её. Я ообщил весь свой пыт моделирования и работы в разных языках и средах. Затем я выбрал наиболее наглядный случай для иллюстрации разницы. И потом даже подчеркнул в тексте, что этот случай — типичный. Типично, что разработка на пайтон идёт быстрее. Типично, что она не требует особых знаний специфики языка, как к примеру, о работе с памяью, и что он содержит более высокоуровневые абстракции, в сравнении с си. Типично, что многих пролем можно избежать, за счёт работы интерпретатора. Типисчно, что время актиного занятия человека разработкой стоит дороже, чем время работы машины (скажем, ночью, пока вышеупомянутый человек спит) — и это делает скорость выполнения менее важным пунктом, чем первые три, что я назвал.
Во-вторых, касательно курсов. Здесь ситуация иная, у меня нет опыта обучения в тысячах вузов, потому обобщение вообще не имеет место. Но есть знание ожиданий преподавателей и вообще всей системы образования, считая министерство, от представителей этой специальности. Я формирую общее решение из текста требований. Затем добавляю частное решение из собственного частного опыта обучения. Частно+общее = полное решение. Если где-то в каком-то вузе решили копнуть немного в сторону от него, например в системное программирование, игру на пианино, или ботанику, то это следует рассматривать как исключение скорее, чем оригинально взятое частное решение.
Вместо списка из трёх вузов где я точно знаю, преподают на делфи, я предлагаю просто подождать, пока кто-нибудь увидит это сообщение и отпишется «у меня тоже было делфи», если я прав — то такой ответ не заставит нас ждать слишком уж долго.
-я бы вообще не учил физиков, что существует консольный способ взаимодействия с системой и с программой. Это достаточно сильно отталкивает от программирования, я это понял очень хорошо, когда навозился с ssh
-первая строчка в первой программе на с++ должна содержать импорт (потому что он без этого не может
Точно так же как и в вашем посте с задачей дифференцииорования Вы взяли свой нехарактерный опыт и обобщили на «всех Естественнонаучников».
Во-первых.
Про задачу. Я не обобщал её. Я ообщил весь свой пыт моделирования и работы в разных языках и средах. Затем я выбрал наиболее наглядный случай для иллюстрации разницы. И потом даже подчеркнул в тексте, что этот случай — типичный. Типично, что разработка на пайтон идёт быстрее. Типично, что она не требует особых знаний специфики языка, как к примеру, о работе с памяью, и что он содержит более высокоуровневые абстракции, в сравнении с си. Типично, что многих пролем можно избежать, за счёт работы интерпретатора. Типисчно, что время актиного занятия человека разработкой стоит дороже, чем время работы машины (скажем, ночью, пока вышеупомянутый человек спит) — и это делает скорость выполнения менее важным пунктом, чем первые три, что я назвал.
Во-вторых, касательно курсов. Здесь ситуация иная, у меня нет опыта обучения в тысячах вузов, потому обобщение вообще не имеет место. Но есть знание ожиданий преподавателей и вообще всей системы образования, считая министерство, от представителей этой специальности. Я формирую общее решение из текста требований. Затем добавляю частное решение из собственного частного опыта обучения. Частно+общее = полное решение. Если где-то в каком-то вузе решили копнуть немного в сторону от него, например в системное программирование, игру на пианино, или ботанику, то это следует рассматривать как исключение скорее, чем оригинально взятое частное решение.
Вместо списка из трёх вузов где я точно знаю, преподают на делфи, я предлагаю просто подождать, пока кто-нибудь увидит это сообщение и отпишется «у меня тоже было делфи», если я прав — то такой ответ не заставит нас ждать слишком уж долго.
-я бы вообще не учил физиков, что существует консольный способ взаимодействия с системой и с программой. Это достаточно сильно отталкивает от программирования, я это понял очень хорошо, когда навозился с ssh
Нет, просто нет. Как раз для научного софта во многих случаях удобнее делать текстовый формат взаимодействия — для gui нужно писать слишком много никак не относящегося к делу коду. Да и непонятно, как нормально заскриптовать взаимодействие нескольких gui программ. Чем же вам ssh так не понравился? Как я вижу все коллеги его без проблем используют, единственно что у не у всех там русские буквы нормально показываются — но они мало кому нужны.
Да и про делфи в вузах тоже удивительно, кажется странным выбором. В Москве (мфти/мгу/и другие) точно C/C++ в качестве базового программирования дают, в том числе на физфаках. По желанию можно брать курсы по всяким питонам, функциональным языкам и т.п.
для gui нужно писать слишком много никак не относящегося к делу коду
В Делфи, к примеру, на форму бросается объект. Затем дабл клик по нему генерирует весь необходимый код (объект появляется в списке на инициализацию, создаётся процедура клика, и даже курсор ставится на то место, куда писать код). А вывод в листбокс там такой же однострочный, как и вывод в консоль. Так что никаких дополнительных затрат по написанию кода нет. Вот в С++ как раз придётся написать код импортирующий ио и скорее всего строки. И стандартную библиотеку, весьма вероятно. И бог ещё знает что.
Чем же вам ssh так не понравился
Тем, что самый простой способ работать по нему — это иметь под рукой ещё третий компьютер с гуи и открытым браузером. Плюс безальтернативная работа с текстом нагоняет ощущения, как от давно позабытого доса, что в современном мире причиняет некоторый дискомфорт. Всегда гадал, какая такая профессиональная деформация заставляет некоторых линуксоидов сносить вообще графическую оболочку и с упоением ковыряться в символьном «интерфейсе».
По желанию можно брать курсы по всяким питонам, функциональным языкам и т.п.
Ну, среди курсов по желанию у нас, к примеру, работа с С++ была, там даже всяким тонким хитростям с битовыми операциями учили. У нас система в университете такая была, что любые опциональные курсы может взять себе любой студент с любого факультета. Так что таким образом программирование мог бы учить не только физик, но и, скажем, филолог. Но в качестве базы С++ шёл только у прикладных математиков, системных аналитиков, системных администраторов и у всех программистов.
А вывод в листбокс там такой же однострочный, как и вывод в консоль. Так что никаких дополнительных затрат по написанию кода нет.
Если в таком духе писать, то и преимуществ относительно командного интерфейса не будет. А вот недостатки есть, значительные. Самый важный на мой взгляд — нетривильно сохранять полную историю, какие команды с какими параметрами и когда запускались. В командной строке это идёт из коробки, причём с удобным поиском, фильтрацией и автодополнением, а в gui нормально реализовать не так просто.
Ну и про простейшую автоматизацию выполнения нескольких программ подряд с передачей данных от одной к другой тоже не стоит забывать — в gui это сложновато, а используется часто.
Ещё как бонус — к командной оболочке я могу подключиться отовсюду, был бы мобильный интернет. И она будет нормально работать даже на медленном/дорогом канале, при этом выглядеть абсолютно привычным образом.
Тем, что самый простой способ работать по нему — это иметь под рукой ещё третий компьютер с гуи и открытым браузером.
Какой ещё третий компьютер и причём здесь вообще браузер? Под рукой нужен ровно один — с которого подключаетесь и за которым собственно сидите. Компьютер, к которому подключаетесь, находится в любом месте, его нужно только один раз настроить — и можно в любой момент подключаться из любой точки мира.
Ну, среди курсов по желанию у нас, к примеру, работа с С++ была
Я же специально написал, что C/C++ входит как база, другие языки — обычно как курсы по выбору.
Если в таком духе писать, то и преимуществ относительно командного интерфейса не будет. А вот недостатки есть, значительные. Самый важный на мой взгляд — нетривильно сохранять полную историю, какие команды с какими параметрами и когда запускались. В командной строке это идёт из коробки, причём с удобным поиском, фильтрацией и автодополнением, а в gui нормально реализовать не так просто.
-Если в таком стиле писать, то у стандартных объектов вывода есть методы по типу «сохранить всю инфу в файл», который проще настроить чем ручной вывод данных в правильном формате.
-Зачем нужна история использования программы, если задачей является получение итоговых данных? Команд с параметрами же в гуи-приложении нет, есть подписаные кнопки, которые нажимает пользователь.
-Я бы не стал употреблять слово «удобно» в одном предложении с символьными интерфейсами без частицы «не». Даже поиск в линуксе не то чтобы очень удобен, и из коробки действительно приходится листать history. Но prompt ещё более мозговыносящий чем их терминал (default OS = Windows, потому что даже по консольно-запускаемым программам-симмуляциям туториалы ориентированы в первую очередь на винду).
Ну и про простейшую автоматизацию выполнения нескольких программ подряд с передачей данных от одной к другой тоже не стоит забывать — в gui это сложновато, а используется часто.
В своём личном опыте я сталкивался только с таким методом: консоль запускает программу и оставляет данные в файле в папке с определённым именем. Следующая команда берёт данные из папки с этим именем. И так далее. То есть всё равно передача данных идёт с использованием файловой системы ОС, так что никакой особой проблемы с тем чтобы сразу так написать в коде — вместо возложения ответственности на то что пользователь заполнит параметры командной строки при запуске — нет.
Ещё как бонус — к командной оболочке я могу подключиться отовсюду, был бы мобильный интернет.
Можно управлять домашним компьютером с мобильника, и видеть на экране привычную графическую оболочку. Точно могу сказать, что интернет пятилетней давности позволял это делать, скорости хватало.
Под рукой нужен ровно один — с которого подключаетесь и за которым собственно сидите.
Да. Один настроенный. Второй, с которого подключаешься. И третий, в котором можно быстро загуглить проблему, если что-то пойдёт не так (во втором гуи может оказаться недоступным из-за особенностей настройки первого).
-Если в таком стиле писать, то у стандартных объектов вывода есть методы по типу «сохранить всю инфу в файл», который проще настроить чем ручной вывод данных в правильном формате.
Как может быть более удобный способ вывести, например, таблицу, в файл, чем что-то вроде питоновских dictwriter или pandas?
Команд с параметрами же в гуи-приложении нет, есть подписаные кнопки, которые нажимает пользователь.
Эм, а как вы задаёте параметры симуляции например — не все же они зашиты в коде? Да и последовательность нажатия кнопок, если функций много, тоже быстро может забыться — а если бы это было в командной строке, то всё сохранится в быстрой доступности.
я бы не стал употреблять слово «удобно» в одном предложении с символьными интерфейсами без частицы «не». Даже поиск в линуксе не то чтобы очень удобен
Как-то на глаз мало что можно улучшить в поиске по истории. Если что простое — то ctrl+r и вводите часть команды которую помните. Если нетривиальное (редко), то history | grep….
То есть всё равно передача данных идёт с использованием файловой системы ОС, так что никакой особой проблемы с тем чтобы сразу так написать в коде — вместо возложения ответственности на то что пользователь заполнит параметры командной строки при запуске — нет.
Это конечно так (в смысле то, что передача данных обычно идёт через файлы). Я немного о другом: если есть несколько gui-программ для разных этапов вычислений/обработки, то не очень понятно как запустить всю последовательность за раз. В командной строке же это очень просто — пишешь буквально ту же самую последовательность команд, что выполнял бы вручную, в нужном порядке в файл. И сразу будут в одном месте команды и все их параметры; потом этот файл можно редактировать, например заменяя входные параметры, и быть уверенным что никаой этап не будет забыт.
Да. Один настроенный. Второй, с которого подключаешься. И третий, в котором можно быстро загуглить проблему, если что-то пойдёт не так (во втором гуи может оказаться недоступным из-за особенностей настройки первого).
Это вы как-то очень странно ssh пользуетесь. Вообще-то вся работа с удалённым компьютером по ssh происходит в отдельном окне терминала, и ничего не мешает держать открытым браузер/другие приложения. Что там может пойти не так до такой степени, я как-то даже представить не могу — всё выглядит и работает абсолютно так же, как если сидеть непосредственно за удалённым компьютером.
Вообще странно видеть, что вы так неперевариваете командную строку. Как-то по своим коллегам вижу, что уж с чем-чем, а с командной строкой и ssh ни у кого проблем не возникает. Как минимум от ~20 до ~70 лет, занимаются астрофизикой, причём большинство даже не численным моделированием, а просто используют программы и программирование как инструмент. И да, default OS как-то так вышло, что у 80+% linux, и много софта нормально работает только под ним. А уж на рабочих станциях, где лежат основные терабайты данных и мощные процессоры, и подавно везде linux.
Как может быть более удобный способ вывести, например, таблицу, в файл, чем что-то вроде питоновских dictwriter или pandas?
Как насчёт убегающих разделителей? Насколько я понимаю, надо в параметр ридера потом вручную передавать информацию о символах разделителя и цитации, т.е. надо быть внимательным, и желательно не писать разнородные данные в один файл. Тогда как в стандартных объектах вывода на гуи прописана какая-то дефолтная токенизация, и пользователю уже даже не обязательно знать как храниться файл — уже всё сделано за него. Безопаснее же.
Эм, а как вы задаёте параметры симуляции например — не все же они зашиты в коде? Да и последовательность нажатия кнопок, если функций много, тоже быстро может забыться — а если бы это было в командной строке, то всё сохранится в быстрой доступности.
Ни зашивка параметров в код, ни забывание последовательности — не проблема для одноразового кода.
Как-то на глаз мало что можно улучшить в поиске по истории.
Если только не добавить интерфейс. Например, сделать как поиск текста на вебстраницах в браузерах, для начала. А вообще-то, если уж писать действия пользователя, то для этого есть специальные инструменты. Слухачи кнопок, рекордеры (иногда даже просто подключаемые как плагин) и всякое такое.
пишешь буквально ту же самую последовательность команд, что выполнял бы вручную, в нужном порядке в файл
Ну, то есть пишется скрипт. Который можно написать и в скриптовом языке программирования. И добавить в проект, чтобы пользователь не шёл в консоль.
Вообще-то вся работа с удалённым компьютером по ssh происходит в отдельном окне терминала, и ничего не мешает держать открытым браузер/другие приложения.
Теперь допустим, что сервер на компьютере-1 настроен таким образом, что подключится можно только программой А. Доступа к компьютеру-1 у вас нет, чтобы просто по другому настроить сервер, пускай он вообще стоит в другой стране, и возятся с ним 3 индуса и сторож, которым объяснить ничего нельзя; но зато есть компьютер-2, вы скачиваете программу А, и оказывается, что каждый её запуск нечаянно все ваши драйвера на видеокарту (особенность конфигурации к-2, не более). Приходится переключатся в режим терминала на компьютере-2, чтобы подсоединиться к компьютеру-1 через А (которая просто реализует протокол ssh с какой-то дополнительной защитой). Примерно так происходил мой первый опыт работы с этой штукой, и он мне не понравился. Мало того, что надо терминалом управлять удалённым компом, так ещё и на своём тоже в терминал переключаться. Проще всего тогда было найти ещё один компьютер, но решение не претендует на универсалность.
И да, default OS как-то так вышло, что у 80+% linux, и много софта нормально работает только под ним.
Учёный должен ещё (кроме работы с данными) работать со статьями, и писать тексты, и делать презентации, и визуализации, и много всякого разного. А о превосходстве офиса майкрософт над опенсорсными аналогами я могу слагать целые легенды и балады. Из этих двух фактов можно заключить, что windows учёному необходима. Кроме того, мне абсолютно неясны механизмы смещения статистики ОС среди учёных относительно мировой в пользу линукса (не вижу причин, почему среди учёных могло бы быть больше чем стандартные 1-2% по миру).
А моё личное отвращение (не имеющее отношения к вопросу об отношении среднестатистического учёного) легко объясняется сильной 23-летней привычкой к внутреннему обустройству Windows, ассоциацией текстового линукса с досом, который я ещё немного помню, и собственным опытом работы с линуксом, где мне пришлось буквально вывернуть своё мышление наизнанку ради дела. С линуксом мне в то времяпришлось больше заниматься настройкой, линковкой, версиями, версиями, компиляторами… И это было 80% времени. Тогда как с виндой я 80% времени выдумывал алгоритмы и архитектуру, и потом реализовывал и оттачивал дебагом свои идеи. Это гораздо интереснее, тем более с блэкджеком и графикой.
Если говорить о вашей статистике, то меня она шокирует. Вот я посмотрел у меня в группе пользователей проги 58 человек, двое используют линукс.
Откройте для себя виртуалки. Пусть программа А виртуалку роняет сколько угодно — а хост-система будет в полном порядке.
Вот я не подумал… Действительно, просто для организации протокола связи много ресурсов не надо, можно было в коробке запустить. Хотя поставить виртуалку и развернуть на ней ОС — это тоже некоторое время занимает. Так что решение с двумя компьютерами сэкономило рабочее время над проблемой.
Но на будущее я запомню. Как же так-то, не догадался виртуалбокс поставить.
Но на будущее я запомню. Как же так-то, не догадался виртуалбокс поставить.
UFO just landed and posted this here
Насколько я понимаю, надо в параметр ридера потом вручную передавать информацию о символах разделителя и цитации, т.е. надо быть внимательным, и желательно не писать разнородные данные в один файл.
Эм, вы вообще как пишете в файл? Если работаете с pandas, то там вообще `dataframe.to_csv('filename.csv')` и вся таблица сохранилась с заголовком и правильными разделителями. Если без pandas, то с dictwriter ненамного больше писать.
Ни зашивка параметров в код, ни забывание последовательности — не проблема для одноразового кода.
Одноразовый код это что-то необычное. Всегда полезно посмотреть, как ведёт себя некоторое выходное значение в зависимости от чего-то, да и просто для повторяемости результата полезно иметь возможность запустить ровно то же самое, что и n времени назад.
Ну, то есть пишется скрипт. Который можно написать и в скриптовом языке программирования. И добавить в проект, чтобы пользователь не шёл в консоль.
Вот смотрите, написали вы на делфи программу, которая при нажатии на кнопку считает что-то. Другой человек написал программу, которая при нажатии на кнопку считает что-то ещё по результатам вашей программы. Как в таком случае запустить обе программы, чтобы с нуля получить весь результат? Вы же не будете в каждую программу добавлять скриптовый язык, смысла в этом нет.
Теперь допустим, что сервер на компьютере-1 настроен таким образом, что подключится можно только программой А.
…
вы скачиваете программу А, и оказывается, что каждый её запуск нечаянно все ваши драйвера на видеокарту
Это реальный случай? Просто подключение по ssh происходит с использованием одноимённой программы (в смысле, которая тоже называется ssh), и она уж точно никак не связана с драйверами видеокарты (!). Кстати, если такие проблемы подключиться по ssh, где нужен только текст, то при удалённой работе в графическом интерфейсе тем более могут возникнуть проблемы.
Учёный должен ещё (кроме работы с данными) работать со статьями, и писать тексты, и делать презентации, и визуализации, и много всякого разного. А о превосходстве офиса майкрософт над опенсорсными аналогами я могу слагать целые легенды и балады. Из этих двух фактов можно заключить, что windows учёному необходима.
Статьи (практически без вариантов) — latex. Презентации и постеры часто тоже, если не нужно особой динамичности. Для презентаций кстати я особой разницы между powerpoint и impress для себя не нашёл, а вот keynote (в маке) на голову выше. Визуализации — это что именно? Графики — понятно, что софт один и тот же во всех ОС. Простые блок-схемы знаю что у нас в inkscape делают (сам не сталкивался).
Ах да, единственный случай, где относительно регулярно требуется MS Office — заполнение всяких заявок и отчётов по грантам, которые бывают очень хитрой формы и открываются только в нём. Ну так проще только для этой задачи запускать виртуалку, чем наоборот.
Я уже описал проблему, думаю понятно. Искать примеры использования этих вещей мне лень, т.к. сам я их не использую, но поверьте, бывают проблемы. Мне кидали файлики, которые парсились неправильно, или только с какой-то левой кодировкой, или с лишними токенами из-за ,/;.
А если это модуль программы, как процедура в делфи, то вы и из консоли её не запустите отдельно.
Да. Режим подключения определяется тем, кто и как настраивал сервер. А программок которые роняют что-то в линуксе море (даже драйвер на графику не поставить, когда есть графика — парадокс). Вообще отдельная от ОС графическая оболочка было для меня новостью тогда. Типа вот есть программа, только окна и кнопки ты рисуешь для неё в отдельной программе-оболочке опять-таки, очень сильно противоречит интуиции.
В графическом не возникало, пока что-то не сломалось, и такой способ оказался недоступным.
Латех придумали верстальщики, чтобы переложить на учёных часть своей работы. Форматированием обязаны заниматься издатели. это всегда так для журналистов и писателей. Но на учёных решили сэкономить, и теперь многие журналы требуют это безумие — чтобы им отправляли статьи на языке разметки. Латех удобен только если набирать формулы, при чём для человека, который не в курсе что их можно набирать в визивиг-редакторе, или на форумах, где этих редакторов нет, а есть только разметки.
Вообще говоря я диссертацию пишу в ворде, и ни за что не открою опенсорсным аналогом, потому что есть большой шанс крашнуть документ. В powerpoint при желании можно сделать motion graphics и примитивненький скрайбинг, не говоря уже о том, что под виндоус существуют более продвинутые программі для презентации. impress начиная с некоторого размера будет не открываться, крашиться, система будет зависать на видеовставках. Инструменты для анимации там почти такие же, только их чуть меньше, и тайминг в них спонтанно сбивается — нет гарантии что одна анимация отработает одинаково каждый раз. С графиками я работаю в 5 программах, 3 из которых принципиально не поддерживаются на линуксах, а две — вебприложения, так что наверное, заработают… Для блоксхем я использую лио визио, либо пару yed + графический редактор (когда завезут фри-фотошоп на линуксе?). Inkscape, конечно, ничего, я им и с виндоуса пользуюсь. Шрифт даже можно свой сделать. Удобная вещь. Но всё таки количество вещей которые можно делать программами на линуксе не только меньше того многообразия на винде, но и меньше того, что необходимо.
А если это модуль программы, как процедура в делфи, то вы и из консоли её не запустите отдельно.
Это реальный случай?
Да. Режим подключения определяется тем, кто и как настраивал сервер. А программок которые роняют что-то в линуксе море (даже драйвер на графику не поставить, когда есть графика — парадокс). Вообще отдельная от ОС графическая оболочка было для меня новостью тогда. Типа вот есть программа, только окна и кнопки ты рисуешь для неё в отдельной программе-оболочке опять-таки, очень сильно противоречит интуиции.
в графическом интерфейсе тем более могут возникнуть проблемы.
В графическом не возникало, пока что-то не сломалось, и такой способ оказался недоступным.
Статьи (практически без вариантов) — latex.
Латех придумали верстальщики, чтобы переложить на учёных часть своей работы. Форматированием обязаны заниматься издатели. это всегда так для журналистов и писателей. Но на учёных решили сэкономить, и теперь многие журналы требуют это безумие — чтобы им отправляли статьи на языке разметки. Латех удобен только если набирать формулы, при чём для человека, который не в курсе что их можно набирать в визивиг-редакторе, или на форумах, где этих редакторов нет, а есть только разметки.
Вообще говоря я диссертацию пишу в ворде, и ни за что не открою опенсорсным аналогом, потому что есть большой шанс крашнуть документ. В powerpoint при желании можно сделать motion graphics и примитивненький скрайбинг, не говоря уже о том, что под виндоус существуют более продвинутые программі для презентации. impress начиная с некоторого размера будет не открываться, крашиться, система будет зависать на видеовставках. Инструменты для анимации там почти такие же, только их чуть меньше, и тайминг в них спонтанно сбивается — нет гарантии что одна анимация отработает одинаково каждый раз. С графиками я работаю в 5 программах, 3 из которых принципиально не поддерживаются на линуксах, а две — вебприложения, так что наверное, заработают… Для блоксхем я использую лио визио, либо пару yed + графический редактор (когда завезут фри-фотошоп на линуксе?). Inkscape, конечно, ничего, я им и с виндоуса пользуюсь. Шрифт даже можно свой сделать. Удобная вещь. Но всё таки количество вещей которые можно делать программами на линуксе не только меньше того многообразия на винде, но и меньше того, что необходимо.
В общем, сойдёмся на том что наш с вами опыт очень сильно различается. Никогда не видел и не могу представить, чтобы ssh уронил что-то помимо себя; кстати при падении чего-то в линуксе практически всегда можно через magic sysrq убить только графическую оболочку или конкретную мешающую программу, а остальные выполняющиеся расчёты никак не пострадают; latex мне, как программисту в прошлом, более понятен чем word, которым я без необходимости не пользуюсь; графики я делаю в одной программе — python называется; на линуксе весь нужный научный и околонаучный софт работает, а вот в винде далеко не все библиотеки легко компилируются, даже для питона.
Единственное, что согласен — при установке драйверов на видеокарту в линуксе возникают проблемы чаще, чем на винде. Ну так это действие нужно сделать всего один раз на компьютере, и можно попросить опытного человека помочь. На винде кстати тоже дааалеко не всегда сразу получается, буквально недавно знакомым настраивал чтобы нормально cuda работала — не с первого раза всё правильно встало. В линуксе же как раз cuda сразу заработала, но оказалось им ещё и игры частенько нужны — а тут без винды никак.
Единственное, что согласен — при установке драйверов на видеокарту в линуксе возникают проблемы чаще, чем на винде. Ну так это действие нужно сделать всего один раз на компьютере, и можно попросить опытного человека помочь. На винде кстати тоже дааалеко не всегда сразу получается, буквально недавно знакомым настраивал чтобы нормально cuda работала — не с первого раза всё правильно встало. В линуксе же как раз cuda сразу заработала, но оказалось им ещё и игры частенько нужны — а тут без винды никак.
Да, если юпитер под боком, то пайтоном можно сделать всё вышеперечисленное, и даже красиво оформить прямо на листе, где он выполняется.
Вот интересная вещь) В линуксе действительно проще компилировать библиотеки. А в виндоусе проще использовать уже скомпилированые, и никогда не иметь проблем с несовпадением версии компилятора, или с нехваткой библиотек, которые лично человеку в задаче не нужны, но их требует для компиляции нужная библиотека.
Если говорить про куду, то у меня с ней был ад именно на линуксе (ведь санчала нужно поставить правильную версию драйверов, что не всегда возможно нормальными способами). А на винде как-то на раз два — всё автоматизировано (в линуксе тоже есть автоматизирующие скрипты, но они постоянно пытаются то скачивать что-то с давно не существующих репозиториев, то загружают версии несовместимые с чем-то что уже стоит в системе, то ещё что-то неожиданное происходит). Вообще столько головняка с версиями всего-на-свете я на винде никогда не имел. Устанавливал по три версии проги, каждая из которых пыталась апгрейдить уже существующую, и решал проблемы банальным перемещением папок. В линуксе ради такого приходится почему-то возиться с системными путями, и при чём эти пути отчего-то гораздо менее удобно организованы чем на винде (хотя редактировать их нужно чаще).
Насчёт научного софта далеко ходить не надо. Простейшая программа для символьных вычислений — маткад — на линуксах не работает, даже из эмулятора не очень чтобы. А оказавшись без ориджина я уже ощущаю себя как без рук (на 3 ноута и комп поставил, не только на рабочий — просто чтобы был, если внезапно понадобится). Попробуйте, может и вы в зависимость впадёте.
Вот интересная вещь) В линуксе действительно проще компилировать библиотеки. А в виндоусе проще использовать уже скомпилированые, и никогда не иметь проблем с несовпадением версии компилятора, или с нехваткой библиотек, которые лично человеку в задаче не нужны, но их требует для компиляции нужная библиотека.
Если говорить про куду, то у меня с ней был ад именно на линуксе (ведь санчала нужно поставить правильную версию драйверов, что не всегда возможно нормальными способами). А на винде как-то на раз два — всё автоматизировано (в линуксе тоже есть автоматизирующие скрипты, но они постоянно пытаются то скачивать что-то с давно не существующих репозиториев, то загружают версии несовместимые с чем-то что уже стоит в системе, то ещё что-то неожиданное происходит). Вообще столько головняка с версиями всего-на-свете я на винде никогда не имел. Устанавливал по три версии проги, каждая из которых пыталась апгрейдить уже существующую, и решал проблемы банальным перемещением папок. В линуксе ради такого приходится почему-то возиться с системными путями, и при чём эти пути отчего-то гораздо менее удобно организованы чем на винде (хотя редактировать их нужно чаще).
Насчёт научного софта далеко ходить не надо. Простейшая программа для символьных вычислений — маткад — на линуксах не работает, даже из эмулятора не очень чтобы. А оказавшись без ориджина я уже ощущаю себя как без рук (на 3 ноута и комп поставил, не только на рабочий — просто чтобы был, если внезапно понадобится). Попробуйте, может и вы в зависимость впадёте.
А в виндоусе проще использовать уже скомпилированые, и никогда не иметь проблем с несовпадением версии компилятора
в реальности всё ровно наоборот. GCC поддерживает обратную бинарную совместимость и библиотеки, собранные GCC разных версий, как правило без проблем используются друг с другом.
А вот в windows библиотеки, собранные разными MSVC, почти всегда бинарно несовместимы -> всегда надо искать либы, собранные конкретно вашей версией MSVC.
проблемы с cuda под linux — конкретный пример, связанный, скорее всего, с отсутствием нормальных дров для конкретной видеокарты под linux.
В линуксе ради такого приходится почему-то возиться с системными путями, и при чём эти пути отчего-то гораздо менее удобно организованы чем на винде (хотя редактировать их нужно чаще).
в линуксе для этого есть update-alternatives. Вы просто выбираете, на какую именно версию программы указывает симлинк myprog. Касательно путей — это вопрос привычки и здравого смысла. Меня лично уже тошнит под виндой указывать пути ко всему подряд
А оказавшись без ориджина я уже ощущаю себя как без рук
Вот поэтому весь стек технологий заменил на C++(местами Rust) + python.
Под все нужные задачи либо есть библиотеки готовые, либо дописал свои. Нужно было работать с cgns из Python — сделал с помощью Cython обёртку по мотивам другого пакета. Нужна отрисовка данных — matplotlib + vtk.
Всё скриптуется, работает в notebook, комбинируется в консоли под linux. Умеет генерировать latex таблицы и графики из сырых данных. Обновился расчёт — запуск одного скрипта + pdflatex = отчёт или статья с обновлёнными графиками и таблицами.
Устанавливается на новую машину быстро с помощью Anaconda + собранные под неё свои пакеты.
Знаю много людей, работающих в том же стиле, что и вы. Вам видимо удобнее по другому в силу каких-то особенностей мышления и привычек. Я не говорю, что какой-то из вариантов лучше или хуже. Видимо я больше склонен к автоматизации, мне так проще. Вам — видимо нет.
Не удивляйтесь, что для кого-то тыкать мышкой менее удобно, чем написать скрипт и запускать в консоли.
Главное чтобы костюмчик сидел.
Плодотворной научной деятельности!
Это реальный случай?
Наверняка реальный. Интеграторы и админы — большие выдумщики. У нас вот в одном из проектов прога для удаленного доступа к продуктиву роняет сеть — и это выдается за фичу!
Блок-схемы большой сложности с компиляцией из схемы классов или блок-схемы в шаблон кода (Python или Java) умеет программа Dia. Рекомендую, очень удобно.
В Делфи, к примеру, на форму бросается объект. Затем дабл клик по нему генерирует весь необходимый код (объект появляется в списке на инициализацию, создаётся процедура клика, и даже курсор ставится на то место, куда писать код). А вывод в листбокс там такой же однострочный, как и вывод в консоль. Так что никаких дополнительных затрат по написанию кода нет. Вот в С++ как раз придётся написать код импортирующий ио и скорее всего строки. И стандартную библиотеку, весьма вероятно. И бог ещё знает что.
вы наверно не в курсе, что в плюсах тоже так можно? И даже более того, стало можно раньше, чем в делфи?
вот тут C#: www.khai.edu/uploads/editor/1/9263/sitepage_154/files/ucheb_progr_informatika.pdf
тут тоже С++: www.khai.edu/uploads/editor/1/2/sitepage_13/files/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B0%20%D0%A1%D0%9F%20%D1%96%D1%81%D0%BF%D0%B8%D1%82%D1%96%D0%B2%205%20%D0%BA%D1%83%D1%80%D1%81%20105%20%D0%BF%D1%80%D0%B5%D0%B4%D0%B2.pdf
тут тоже С++: www.khai.edu/uploads/editor/1/2/sitepage_13/files/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B0%20%D0%A1%D0%9F%20%D1%96%D1%81%D0%BF%D0%B8%D1%82%D1%96%D0%B2%205%20%D0%BA%D1%83%D1%80%D1%81%20105%20%D0%BF%D1%80%D0%B5%D0%B4%D0%B2.pdf
UFO just landed and posted this here
Как-то вы странно знали паскаль. На сколько помню, в паскале/делфи память выделяется и освобождается как раз руками, по сему этим уши прожжужали уже в школе.
Там есть такая штука как динамические массивы — вот для них память выделяется компилятором, надо лишь длину указать.
А больше для числодробилок и не надо.
А больше для числодробилок и не надо.
Именно. Память нужна не лично программисту, а переменным в алгоритме, который он сочинил. Если он может использовать абстракцию массива не вдаваясь в детали, как внутри она устроена, и как выделяет-освобождает память, то и не нужно вдаваться.
Касательно же прямой работы с памятью, поле того как я более плотно познакомился с rust я начал удивляться, как это можно было придумать такую странную контринтуитивную штуку как С. Если считается необходимой работа с памятью для быстрых вычислений, то почему же её не делают обязательной при объявлении, и не вводят счётчики ссылок? В научных вычислениях, впрочем, я пока rust не применял, жду пока полезные библиотеки перепишут, тогда попробую поднять скорость своих программ с экспериментами. Но на С++ я это делать не рискну — больше нервов потрачу на всякие вылазящие ub, чем пользы нанесу.
Касательно же прямой работы с памятью, поле того как я более плотно познакомился с rust я начал удивляться, как это можно было придумать такую странную контринтуитивную штуку как С. Если считается необходимой работа с памятью для быстрых вычислений, то почему же её не делают обязательной при объявлении, и не вводят счётчики ссылок? В научных вычислениях, впрочем, я пока rust не применял, жду пока полезные библиотеки перепишут, тогда попробую поднять скорость своих программ с экспериментами. Но на С++ я это делать не рискну — больше нервов потрачу на всякие вылазящие ub, чем пользы нанесу.
как это можно было придумать такую странную контринтуитивную штуку как С
Минимальный оверхед по памяти и тактам, вполне себе интуитивно, хотя используется всё меньше (в C++ отличия очень больший, другой язык всё таки).
Потому что Си как близкий к железу системный язык должен иметь возможность работать с памятью в любом формате, а не диктовать свой. А построить удобную абстракцию над сырыми указателями мешает уже бедность языка.
В современном же C++ основная рекомендация (которую вы пропустили) — использовать std::unique_ptr и std::shared_ptr вместо сырых указателей (второй дает тот самый подсчет ссылок), и std::vector вместо динамических массивов.
В современном же C++ основная рекомендация (которую вы пропустили) — использовать std::unique_ptr и std::shared_ptr вместо сырых указателей (второй дает тот самый подсчет ссылок), и std::vector вместо динамических массивов.
Не делайте научные расчёты на C / C++ / Rust. Они не созданы для быстрых научных расчётов.
В Си Вы будете бороться с языком, который чуть выше ассемблера, и нужен для писания драйверов.
C++ / Rust — сложные языки, для тех, кто пишет софт надолго, такой, как браузер, например, или построитель графиков.
Возьмите любой язык, в котором есть сборка мусора: C#, Java, Pascal, Fortran, Dlang, Golang, Julia, CommonLisp.
Поищите под этот язык нужные Вам лично библиотеки, и пишите так:
прототип в Calc / Excel -> алгоритм и тесты на Python -> производительный код на вышеуказанных. Вы потратите гораздо больше времени на освоение концепций C++ / Rust, чем сэкономите на времени вычислений. Лучше, конечно, фортран и правильная книжка к нему.
В Си Вы будете бороться с языком, который чуть выше ассемблера, и нужен для писания драйверов.
C++ / Rust — сложные языки, для тех, кто пишет софт надолго, такой, как браузер, например, или построитель графиков.
Возьмите любой язык, в котором есть сборка мусора: C#, Java, Pascal, Fortran, Dlang, Golang, Julia, CommonLisp.
Поищите под этот язык нужные Вам лично библиотеки, и пишите так:
прототип в Calc / Excel -> алгоритм и тесты на Python -> производительный код на вышеуказанных. Вы потратите гораздо больше времени на освоение концепций C++ / Rust, чем сэкономите на времени вычислений. Лучше, конечно, фортран и правильная книжка к нему.
Fortran вычеркните из списка, пожалуйста, т.к. там нет сборщика мусора. Но для многих числодробительных операций он действительно подходит идеально, за исключением может быть деревьев и прочих структур, которые плохо ложатся на массивы (тот же SciPy представляет собой биндинги преимущественно именно к фортрановским библиотекам).
Да, ошибся я. Но всё же, интегрировать и дифференцировать уж лучше на фортране, чем на Расте, так ведь?
Да, лучше но Раст никто не используют для научных расчетов. Фортран попрост иногда неудобен и пишут на C/C++ более того даже переписывают редкий managed язык имеет аналоги MPI/openmp/OpenCL/Cuda поэтому выбор застревает на C/C++/Fortran. А т.к. большинство учённых уже имеет в комплекте с компилятором intel mkl то боль от написания биндингов к Фортрану постепенно уходит и все больше новых проектов вычислительной пишутся именно на C/C++.А вот обработкой данных от этих расчетов уже и занимаются на Julia/Python/MATLAB(Octave)
OpenCL и Cuda как раз не привязаны к языку — они с одинаковым успехом могут вызываться хоть из С, хоть из фортрана, хоть из питона.
Ага а Cuda ядра/OpenCL ядра вы тоже можете на python писать или все таки приходится использовать хост компилятор вендора (совместимый с C). Хотя в opencl вроде можно строчку скормить и самим opencl скомпилить так что да с opencl проканает
Cuda абсолютно так же принимает строку на вход, как и opencl. И от C в них по сути только синтаксис, модель вычислений-то совсем другая. То есть разницы, вызывать opencl из фортрана или питона, особой нет.
То что такой режим есть в случае opencl есть не значит что им можно пользоваться если у вас FPGA удачи вам компилить вызовами opencl из python (компиляция занимает пару дней). Если у вас Xeon phi то об поддержке opencl можно забыть и тут тоже все что не C/Fortran --мимо. Вывод python применим только для gpgpu. В остальных случаях C/C++/Fortran
Можете всё-таки ставить знаки препинания, хоть иногда?
Сам я opencl только на gpu использовал, и это явно самая частая область его применения. Но сходу в гугле ничего не показывает, что компиляция для fpga из питона медленнее — есть пруфы? И вообще это странно выглядит.
Сам я opencl только на gpu использовал, и это явно самая частая область его применения. Но сходу в гугле ничего не показывает, что компиляция для fpga из питона медленнее — есть пруфы? И вообще это странно выглядит.
Пардон, неправильно объяснил.
Она не из питона медленнее она вообще медленнее python/C++ неважно. Просто для FPGA такой подход неприменим, но ничто в принципе не запрещает нам грузить собранные бинари в ускоритель из pythonа. Вообщем, признаю неправоту, все можно делать и из python(даже гибридную модель MPI+opencl)
Она не из питона медленнее она вообще медленнее python/C++ неважно. Просто для FPGA такой подход неприменим, но ничто в принципе не запрещает нам грузить собранные бинари в ускоритель из pythonа. Вообщем, признаю неправоту, все можно делать и из python(даже гибридную модель MPI+opencl)
Во-первых, я отвечал на
Понимаете, тут, видимо бага в моём образовании: я инженер. И когда мне говорят «надо считать науку», я иду и ищу «считалку для науки», а когда говорят «нужен редуктор для станка», я в первую очередь полезу в справочник общепромышленных редукторов.
Я смотрю, откуда у продукта ноги растут. Фортран создавался для научных расчётов, и его название расшифровывается как «FORmulas TRANslator». Значит, его берём. LUSH создавался автором тоже специально для научных расчётов — берём.
Rust сначала был хобби-проектом, потом стал системным языком в проекте Mozilla, а потому он будет удобен системщикам, но не учёным.
Язык C with Classes был создан Бьярне Страустру-
пом как результат синтеза идей языков C и Simula. Этот
язык вышел из употребления сразу после реализации
его наследника — языка C++. [ПРОГРАММИРОВАНИЕ принципы и практика использования С++ Исправленное издание: Бьярне Страуструп, стр.840-841]. То есть, опять же, системщиком для системщиков.
Ну, и всё-таки, мы в комментария к статье, в которой автор показывает, что с C++ и с Delphi он не совладал, а вот Python волшебным образом спас положение.
В научных вычислениях, впрочем, я пока rust не применял, жду пока полезные библиотеки перепишут,от автора статьи.
Понимаете, тут, видимо бага в моём образовании: я инженер. И когда мне говорят «надо считать науку», я иду и ищу «считалку для науки», а когда говорят «нужен редуктор для станка», я в первую очередь полезу в справочник общепромышленных редукторов.
Я смотрю, откуда у продукта ноги растут. Фортран создавался для научных расчётов, и его название расшифровывается как «FORmulas TRANslator». Значит, его берём. LUSH создавался автором тоже специально для научных расчётов — берём.
Rust сначала был хобби-проектом, потом стал системным языком в проекте Mozilla, а потому он будет удобен системщикам, но не учёным.
Язык C with Classes был создан Бьярне Страустру-
пом как результат синтеза идей языков C и Simula. Этот
язык вышел из употребления сразу после реализации
его наследника — языка C++. [ПРОГРАММИРОВАНИЕ принципы и практика использования С++ Исправленное издание: Бьярне Страуструп, стр.840-841]. То есть, опять же, системщиком для системщиков.
Ну, и всё-таки, мы в комментария к статье, в которой автор показывает, что с C++ и с Delphi он не совладал, а вот Python волшебным образом спас положение.
первую очередь полезу в справочник общепромышленных редукторов.желательно, последней редакции, а не 1907 года.
говорят «надо считать науку», я иду и ищу «считалку для науки»,
Фортран создавался для научных расчётов… и на сегодня многими считается устаревшей технологией.
В науке есть понятие «state of the art». Очень часто этот state of the art в одной отрасли достигается за счёт применения последних достижений из других областей. Например, недавно случился прорыв в Cryo-Electon Microscopy (of biomolecules), которая ближе к молекулярной биологии так как вместо вместо фотонных детекторов стали применять электронные, которые из физики полупроводников.
Считаться он может чем угодно но если посмотреть что запускают на кластерах то это в 70% случаев Fortran. И не забывайте что современный Фортран и f77 это как C++17 и c89
Откуда статистика? У нас на кластере 95% — это С и С++. Тем более что на сегодня большая часть вычислительной мощности кластеров — это GPU, хост-программы для которых на fortran я не видел.
К сожалению пруф уровня слухов четырехлетней давности от админов Ломносова-1, возможно все и поменялось, но, наблюдая на чем пишут знакомые физики/разработчики числ. методов, то не уверен, что доля Фортрана упала сильно думаю 30-50% есть и сейчас. Только недавно пошел тренд переписывать все на C++. P.S. Cuda поддерживает гость программы на Fortran. OpenACC тоже поддерживает Fortran. Пока стандартные библиотеки netlib используют Фортран так и будут продолжать на нем писать. Но, опять же, отмечу, что современный Фортран и f77 это как C++17 и c89
Вот здесь поддержу всеми руками — каждому овощу (инструменту) своё место.
Потому что гвоздь, завёрнутый отвёрткой, держит хуже шурупа, забитого молотком.
При обсчёте математики на C++ на мой взгляд слишком велики накладные расходы на мероприятия, обеспечивающие сам расчет.
Потому что гвоздь, завёрнутый отвёрткой, держит хуже шурупа, забитого молотком.
При обсчёте математики на C++ на мой взгляд слишком велики накладные расходы на мероприятия, обеспечивающие сам расчет.
UFO just landed and posted this here
Если взять тот же Eigen и прочие специализированные библиотеки, то да.
Вероятно сравнивают только в рамках стандартной библиотеки. В этом случае, по сравнению с тем же Fortran, бойлерплейта много получается.
Вероятно сравнивают только в рамках стандартной библиотеки. В этом случае, по сравнению с тем же Fortran, бойлерплейта много получается.
в рамках стандартной библиотеки. В этом случае, по сравнению с тем же FortranНо зачем?
Сам удивляюсь, но часто учёные не хотят искать библиотеки. И даже если им найти и показать, они будут делать как привыкли… Потому что работает. И учить, по возможности, они ничего нового не хотят.
Потому, что «Вы, холопы, ничего не понимаете, и как вы вообще посмели ставить под сомнение мой УМ и ГЕНИЙ!..»
*многозначительная театральная пауза*
Весь пост как-раз об этом. И все комменты. Ну, кроме тех, где сравниваются спецязыки и библиотеки… И тех, где срутся о плюсах… Короче, некоторые комменты тоже об этом.
Ладно, это была пародийная гипербола на пару моих знакомых, надеюсь, никто не примет на свой счёт. Но, всё-таки, важнейшими из наук являются социальные, и без их развития мы просто не сможем эффективно передавать друг другу до абсурда огромный объём знаний, который у нас есть и будет есть.
*многозначительная театральная пауза*
Весь пост как-раз об этом. И все комменты. Ну, кроме тех, где сравниваются спецязыки и библиотеки… И тех, где срутся о плюсах… Короче, некоторые комменты тоже об этом.
Ладно, это была пародийная гипербола на пару моих знакомых, надеюсь, никто не примет на свой счёт. Но, всё-таки, важнейшими из наук являются социальные, и без их развития мы просто не сможем эффективно передавать друг другу до абсурда огромный объём знаний, который у нас есть и будет есть.
UFO just landed and posted this here
вместо тогоне вместо, а параллельно.
предлагается изучать социальные наукиДля начала достаточно просто вежливости и учтивости.
А второе в долгосрочной перспективе сильно эффективнееНашей жизни не хватит, судя по всему. Поэтому с точки зрения личного интереса индивидуума сильно эффективней учитывать несовершенство окружающих людей, чем ждать, пока они станут адекватнее. Плюс таким образом «вежливый» индивидуум помогает также быть эффективным и своему собеседнику с когнитивными искажениями.
Мусье, простите мою заносчивость в некоторых выражениях, но откуда вы, чёрт подери, вытащили это жлобское выражение «когнитивных искажений»? Уж не психологи ли вам его подсунули? Те, которые изучают, как можно исправить те или иные «заносчивости»?
И ваше предложение «избавляться от первопричины», это призыв убить всех человеков?
И ваше предложение «избавляться от первопричины», это призыв убить всех человеков?
Вы сами ответили на вопрос:
В статье (мы же не просто в чятике, да?) сказано, что автор в институте изучал Паскаль, а потом его как-то занесло в лабораторию, где был написан код на крестах и он не работал, затем переписан на Delphi и тоже не работал, а затем переписан на Python и вот магия Питона спасла юного героя.
К тому же, я меряю по себе. Я, хоть и прочитал книжку Стровструпа (изд 2010 года «ПРОГРАММИРОВАНИЕ принципы и практика использования С++») и даже примеры делал, совершенно уверен: если мне доведётся писать программу длиннее 2000 строк, то выйдет откровенное говнище.
При умении и знании языкаа также при знании библиотек и множества «острых граней» C++.
В статье (мы же не просто в чятике, да?) сказано, что автор в институте изучал Паскаль, а потом его как-то занесло в лабораторию, где был написан код на крестах и он не работал, затем переписан на Delphi и тоже не работал, а затем переписан на Python и вот магия Питона спасла юного героя.
К тому же, я меряю по себе. Я, хоть и прочитал книжку Стровструпа (изд 2010 года «ПРОГРАММИРОВАНИЕ принципы и практика использования С++») и даже примеры делал, совершенно уверен: если мне доведётся писать программу длиннее 2000 строк, то выйдет откровенное говнище.
Ну не повезло вам с преподавателем. Мне можно было писать хоть на чем. Хоть в экселе, хоть в асме — все исключительно на мое усмотрение. Единственное требование — если возникнут вопросы, то я должен рассказать о любой мелочи, которые происходят в вычислениях.
А теперь вопрос: зачем мне нужно было изучать Си++?
А теперь вопрос: зачем мне нужно было изучать Си++?
Nick_mentat, Вы не использовали в свое время библиотеку Numerical Recipes? Численные методы там реализованы для многих языков программирования.
Вы вообще уверены что вам нужен ЯП общего назначения, а не готовые решения для мат расчетов? Посмотрите в сторону maxima.sourceforge.net и GNU Octave.
Как учёный, который тоже решает свои задачи с помощью программирования, вынужден не согласится с автором. Мне кажется, в статье частный опыт автора излишне обобщен на общую ситуацию, отчего выводы получились излишне смелыми.
При этом в науке всё большую роль играет именно обработка данных с помощью специализированного ПО. Доля «разработки ПО» в научной деятельности быстро растёт. В связи с этим среди ученых все большее распространение приобретает мнение, что изучение теории и практики разработки ПО так же необходимо, как изучение математики. Культура разработки ПО становится частью Good Scientific Practice. При чём это мнение не только среди молодых учёных приобретает распространение, но и среди опытных профессоров за 50-60. Даже если такой профессор сам за жизнь ни одной строки кода не написал — его подчинённые пишут код и профессор со временем понимает, какую большую роль код играет в научной работе его группы, выделяет опытного учёного из своих подчинённых ответственного за код, сталкивается с проблемами некачественного софта и требует, что бы разрабатываемый софт соответствовал определенным критериям качества т.к. иначе следующее поколение аспирантов не сможет им пользоваться/развивать его.
Код никто не защищает от неправильного ввода и нет никакого UX. Код пишется для того чтобы с ним работали учёные, аспиранты, и специально обученные студенты, и никогда — типичные_пользователи и хакеры.Это было так в 1970х в СССР. Действительно, значительная часть преподавателей программирования на факультетах физики или математики бывшего СССР, которые сами в этих 70х-80х учились и получали опыт нередко продвигают такой подход. То есть предлагают учёным сознательно отказаться от проверок и перестраховок в коде, отказаться от GUI и документации кода ради экономии времени утверждая, что «учёный — не пользователь, он знает что делает». Одна далеко не все так считают, и не все так считали в 1970. На сегодняшний день наиболее признанный и «уважаемый» научный код обычно так не разрабатывается. По моему опыту, в современной науке этот подход почти умер. Причин несколько. Научный код становится сложнее, растет количество людей, использующих один и тот же код. Практика показала, что либо сам автор кода через 3 года забывает, что он написал и как этим пользоваться, либо его студенты/последователи/коллеги попытается продолжить/развит его работу и «тяп-ляп» код приведет к замедлению работы учёного и ошибкам. Ошибкам самым опасным, когда программа «работает», результат правдоподобен, но не верен из-за неверного использования ПО. Такие ошибки очень поздно диагностируются. Более того, в современной науке in-house closed source software — это уже тревожный звоночек для рецензентов. При публикации статьи, если указано, что использовалось закрытое самописное ПО — это может быть поводом для критики со стороны рецензентов в духе: «а почему вы не используете общепризнанные проверенные программы или не расширяете их под свои потребности»? Всё больше и больше научного софта живёт на github/sourceforge/публично доступно на сайтах исследовательских групп. Я уже много раз слышал от людей из МФТИ, МГУ, Киевского Физ-Фака, людей из DESY (Гамбург), Ecole polytechnique (Париж), американских учёных истории о такого рода:
Мы написали код, сделали исследование, потом обнаружили что в коде ошибка/код неверно использовался (из-за отсутсвия UX и документации) и год-два работы 2-10 учёных пошли коту под хвост.Или
Ребята сделали софт, получили интересные результаты, несколько публикаций было, а потом оказалось что в софте была ошибка/софт неправильно использовался и результаты «не совсем правильные».При этом в большинстве случаев эти истории не становятся публичными, и статьи не отзываются. Об этом рассказывают по секрету за кружкой пива в духе «у моего `друга` была проблема...».
При этом в науке всё большую роль играет именно обработка данных с помощью специализированного ПО. Доля «разработки ПО» в научной деятельности быстро растёт. В связи с этим среди ученых все большее распространение приобретает мнение, что изучение теории и практики разработки ПО так же необходимо, как изучение математики. Культура разработки ПО становится частью Good Scientific Practice. При чём это мнение не только среди молодых учёных приобретает распространение, но и среди опытных профессоров за 50-60. Даже если такой профессор сам за жизнь ни одной строки кода не написал — его подчинённые пишут код и профессор со временем понимает, какую большую роль код играет в научной работе его группы, выделяет опытного учёного из своих подчинённых ответственного за код, сталкивается с проблемами некачественного софта и требует, что бы разрабатываемый софт соответствовал определенным критериям качества т.к. иначе следующее поколение аспирантов не сможет им пользоваться/развивать его.
Это было так в 1970х в СССР
А ещё так было в Гарварде в 2000-е. И в университете Северной Каролины в 2010-х. И в Карловом университете в 2015-м. «in-house closed source software» — это повсеместная практика, никак нее связанная с СССР. Я её встречаю в статьях гораздо чаще, чем ссылки на гитхаб. Причины тут две 1) хороший код — можно запатентовать и получать доход 2) плохой код — стыдно показать, да и всё-равно никто не разберётся. Часто сталкивался с этим, когда и самому нужен такой код, а в итоге приходится писать всё самому. Часто бывает так что опубликованы версии для матлаба и с++, матлаб версия работает, а си-версию надо самому доделывать, чтобы она хотя бы начала компилироваться. Вот это я очень не люблю, почти месяц из-за таких умельцев потратил на кодинг. Тоже хорошая кулстори, про очень долгий дебаг. Вместо интерфейса у них было бесчисленное множество аргументов командной строки, а в документации кое-что перепутано.
Так что роста значения и качества программ в науке я пока не замечаю.
Что касается историй о потеряных эн годах, то в научном мире есть исследования других групп — которые в любой момент могут перепроверить результат (и это делается для многих важных открытий), не думаю что такой обман может долго жить, даже если рассказан только по секрету. Гораздо большую проблему, на мой взгляд, представляют те споры с регулярным выпуском статей на тему того что проекция объекта круг — нет квадрат — нет круг, когда объект, вообще-то, цилиндр. И вместо объединения подходов создаётся штамповка статей где они противопоставляются.
А ещё так было в Гарварде в 2000-е. И в университете Северной Каролины в 2010-х. И в Карловом университете в 2015-м. «in-house closed source software» — это повсеместная практикаКоторая сегодня воспринимается как устаревшая и пагубная и сходит на нет.
хороший код — можно запатентовать и получать доходДля этого не требуется закрывать код, более того, это даже может мешать. Есть много примеров платного open-source научного софта. Обычно он распространяется дешевле/бесплатно для Академии и дороже для коммерческого использования. Очень часто тем кто пользуется таким (в т.ч. платным) софтом важно знать что там внутри и иметь возможность «допилить для себя». Ну и самое главное — лишь очень маленькая часть научного софта коммерциализируется. Кроме того патенты на ПО в ЕС (и РФ) запрещены.
плохой код — стыдно показатьтоже не работает. Во-первых, если его стыдно показать — значит и рецензенты не слишком склонны будут доверять результатам. Все больше рецензенты обращают на это внимание. Если даже опубликовать такие результаты — их не процетируют ибо «да фиг знает, что они там насчитали». Во-вторых, учёные всё меньше стыдятся т.к. «все такие».
-версию надо самому доделывать… почти месяц из-за таких умельцев потратил на кодинг… Вместо интерфейса у них было бесчисленное множество аргументов командной строки, а в документации кое-что перепутано.И с этим сталкиваются почти все учёные сегодня, поэтому всё меньше это толерируется и всё большее распространение приобретает культура разработки ПО и его публикации. Высока вероятность того, что если код такой плохой, то другие учёные не захотят с ним возиться и займутся чем-то другим, а значит автор плохого кода не получит признания и цитирований.
Так что роста значения и качества программ в науке я пока не замечаю.Selection Bias. Я в последние 5 лет прям на глазах научные группы открывают свои публичные репозитории. Моя область — fluorescence spectroscopy и computational structural modeling, также я соприкасаюсь с EPR, SAXS, Cryo-EM. И везде я вижу как нучные группы прямо наперегонки стараются публиковать свой софт, привлекать к нему пользователей и участников разработки. Все понимают, что кто первый наберет комьюнити — тот застолбит для себя влияниеи авторитет в области. Практически все известные мне группы, которые пользуются наибольшим авторитетом в моей области (big shots), публикуют сфой софт. Появляются качественно написанные и хорошо документированные проекты.
в любой момент могут перепроверить результат (и это делается для многих важных открытий)Только этих перепроверяемых открытий — малая доля от всех исследований. Если результат публикуется без кода — ему меньше доверяют, его реже перепроверяют (не интересно), его меньше цитируют. Есть вероятность, что его просто проигнорируют, и потом кто-то другой получит (почти) тот же результат, но опубликует такой софт, что другие смогут им пользоваться и именно он получит большую часть признания, а не тот кто «первый». Я знаю парочку таких примеров.
не думаю что такой обман может долго житьМожет и живет т.к. обычно подобные результаты никому не нужны и никому не интересны. Неуловимый Джо. На них не опираются и почти не цитируют.
Для этого не требуется закрывать код, более того, это даже может мешать. Есть много примеров платного open-source научного софта.
Я так сказал не потому что считаю правильным такой подход. я просто знаю человека который пилил программу пока учился в аспирантуре, а потом начал её продавать. Для учёных скидок нет, исходного кода нет ни для кого. И пока другие не сделают так же (а программа действительно крута), вряд ли кто-то сможет доступиться к такому функционалу напрямую.
При этом цитировали его статью почти везде в области. Просто чтобы упомянуть «он смог добиться результатов такой точности».
Я в последние 5 лет прям на глазах научные группы открывают свои публичные репозитории.
А сколько специалистов по моделированию? Вполне вероятно, что те же 1-2 на команду, где остальные не знают как это делать и полагаются во всём на коллег?
В примере из поста, мне кажется, всё сводится к тому, что в силу каких-то частных обстоятельств, у автора для своей задачи реализация на Python удалась лучше всего. При этом был сделан вывод, что это следствие системных недостатков C++ и Delphi в контексте его задачи. На мой взгляд, пример автора не репрезентативен по нескольким причинам.
1. Методологически наиболее корректным (стандартным) подходом для численного решения систем диф-инт уравнений является не написание соотв. кода на незнакомом языке программирования с нуля, а
a) Использование специализированного мат. пакета типа Mathematica, Maple и т.п.
б) Использование библиотек для численного решения таких уравнений для какого-то из языков: ODEINT, GSL, SciPy…
2. В описанном примере уровень познаний в применяемых технологиях не очень высокий. При этом делаются выводы именно об этих технологиях, хотя причина возникающих проблем не в языках. Похоже на анекдот «без ног не слышит»:
Или вот ещё пример:
3. Субъективные оценки (вкусовщина) и контекстно-зависимые особенности технологий представляются как преимущества/недостатки. Например «вам нравится, что все 66 коэффициентов объявлены и заданы в начале, а не в любом месте кода». Хотя в любом языке программирования можно объявлять все переменные в начале. В Дельфи же у программиста не выбора, что не всегда преимущество и зависит от ситуации.
1. Методологически наиболее корректным (стандартным) подходом для численного решения систем диф-инт уравнений является не написание соотв. кода на незнакомом языке программирования с нуля, а
a) Использование специализированного мат. пакета типа Mathematica, Maple и т.п.
б) Использование библиотек для численного решения таких уравнений для какого-то из языков: ODEINT, GSL, SciPy…
2. В описанном примере уровень познаний в применяемых технологиях не очень высокий. При этом делаются выводы именно об этих технологиях, хотя причина возникающих проблем не в языках. Похоже на анекдот «без ног не слышит»:
анекдот про таракана
К примеру, совершенно неясно, почему поведение Delphi и C++ реализаций отличается и является ли это следствием особенностей языков. Легко можно себе представить ситуацию, когда поведение программ обратное — Delphi падает, а C++ выдает некорректный результат. Также интерпретатору Python приписываются магические свойства «помогает доброму питону увидеть, сколько памяти требует моё число», хотя на самом деле, возможно, в Python просто использовался float64 вместо float32 в Delphi. Если же применялась длинная арифметика (mmpath?), то почему не применить ее в C++/Delphi? Опыт 1-й: берем таракана, отрываем ему 2-е ноги, свистим таракан убегает!
Опыт 2-й: берем отрываем таракану еще 2-е ноги, свистим таракан убегает!
Опыт 3-й: берем отрываем таракану последние ноги, свистим таракан стоит!
Вывод: таракан без ног не слышит!
Опыт 2-й: берем отрываем таракану еще 2-е ноги, свистим таракан убегает!
Опыт 3-й: берем отрываем таракану последние ноги, свистим таракан стоит!
Вывод: таракан без ног не слышит!
Или вот ещё пример:
написать абстрактный код, который следит за переменными в потоках самых разнообразных вычислений и даёт им больше памяти при необходимости — не забывая в итоге приводить типы к менее ёмким, чтобы не засорять память — это значит написать значительную часть интерпретатора PythonСовершенно некорректные посылы и выводы. Python не «следит за переменными в потоках», не «даёт им больше памяти при необходимости», не «приводит типы к более емким», во всяком случае не больше чем C++. Этим занимаются соотв. библиотеки длинной арифметики, которые есть и для C++. Ну и «значительная часть» интерпретатора Python — просто преувеличение.
3. Субъективные оценки (вкусовщина) и контекстно-зависимые особенности технологий представляются как преимущества/недостатки. Например «вам нравится, что все 66 коэффициентов объявлены и заданы в начале, а не в любом месте кода». Хотя в любом языке программирования можно объявлять все переменные в начале. В Дельфи же у программиста не выбора, что не всегда преимущество и зависит от ситуации.
если вы в численных методах оскоромились ошибкой плавающей арифметики, то это не заслуга питона, что он всегда использует 64-битные float (а плюсы и паскаль дают вам ассортимент из 32, 64 и 80-битных). А просто ваше тупое везение.
В следующий раз вашу цивилизацию разрушит дятел не из 23, а из 55 бита мантиссы. Причём это будет не мгновенный крах, а плавное накопление погрешности, за которой вы не следили.
В плюсах, кстати, вещественная арифметика по-умолчанию 64-битная (а компилятор подпольно может ещё более широкие типы в промежуточных вычислениях использовать). Просто надо один раз выучить язык и писать всюду double.
float только память экономит, больше от него никакой пользы.
В следующий раз вашу цивилизацию разрушит дятел не из 23, а из 55 бита мантиссы. Причём это будет не мгновенный крах, а плавное накопление погрешности, за которой вы не следили.
В плюсах, кстати, вещественная арифметика по-умолчанию 64-битная (а компилятор подпольно может ещё более широкие типы в промежуточных вычислениях использовать). Просто надо один раз выучить язык и писать всюду double.
float только память экономит, больше от него никакой пользы.
Приходилось численно решать дифуры для диплома. На простом С++ и под GPU.
Самое сложное было вкурить в разностную схему, для всего остального были контейнеры STL и интеловская реализация double precision. Параметры итерационного метода решения СЛАУ просто логировал и смотрел, на какой итерации они «улетали вникуда».
Самое сложное было вкурить в разностную схему, для всего остального были контейнеры STL и интеловская реализация double precision. Параметры итерационного метода решения СЛАУ просто логировал и смотрел, на какой итерации они «улетали вникуда».
Физик. Для развлечения разбираюсь в Julia. Пока что более всего радует более привычный Fortran.
Добрый день, уважаемый коллега! Я произвожу физические расчёты по работе и надеюсь, что мой опыт может быть полезным здесь. [Длинна у этого коммента получилась почти статейная, но в статью это превращать я не вижу смысла.]
Когда я в районе N лет назад, свеженькая и зелёненькая, пришла из Универа в НИИ писать диссер, первая я же вещь, от которой я сильно прибалдела, это то, как хорошо люди, чья профессия (ну, официально-то) не программирование, шарят в языках и технологиях. Тут были и С/С++, и Python, и Matlab, и Julia, и R (но, по-честноку, на крестах писалось и пишется 2/3 всего кода, а остальное, по моим глазомерным прикидкам, составляет всего 1/3), для работы на серверах использовались bash и perl, а до кучи к этому мои коллеги знали и были готовы с интересом обсудить за чашкой кофе кучу прочего, казалось бы, совсем не связанного: SQL и noSQL БД, html/php/JavaScript/CSS, bf и кучу всего ещё. Так же в «джентельменский набор» уважаемого коллегами сотрудника лаборатории входило знание основных паттернов программирования и основ вычислений на GPU (или, программа минимум — запуска своей программы в несколько процессов на нескольких ЦПУ). Крутым качеством считалось умение написать «самодокументированный» поддерживаемый код (хотя писать комменты многие мои коллеги крайне не любят и представление о «самодокументированности» у них бывает несколько завышенным. что уж там, мне тоже мои программы кажутся кристально ясными и без всяких комментов… где-то первые два дня после написания, а потом я радуюсь, что комменты я всё-таки оставила ;)) ).
Причины тому были достаточно просты:
В вашей статье я заметила определённое количество бед, связанных с организацией рабочего процесса в организации (что-то имеет место и у нас):
Итого: работа в науке имеет свои специфические горести и радости, а ещё содержит в себе кучу палок о двух концах. Например, само слово «учёный» подразумевает человека, который много чего изучает, учит. Например, высшую математику, как свой рабочий инструмент (хотя он, может, и не профессиональный математик), или программирование (хотя и не программист) или, например, основы геологии (подставьте сюда любую науку, которая не ваша), если коллеги из соседнего НИИ просят помочь с расчётами. Даже с CMS'ами и кастомным довёрстыванием сайтов иногда, ведь нужны же вашим проектам сайты, а денег нет. Короче, разбираться приходится быстро, чёрт пойми в чём, и чем качественнее, тем лучше. С одной стороны — напряжно, с другой — весело и всё время что-то новое. За последнее, как я подозреваю, мы и любим эту работу и стараемся в ней профессионально расти.
И спасибо создателям языком программирования и библиотек для научных вычислений за то, что облегчают наш труд, а местами в принципе делают его возможным.
P.S. Как сказала мне ещё в студенчестве одна мудрая пожилая доктор наук: «Тебе что, не пофиг на каком языке программировать? Взяла методичку и вперёд!»
Когда я в районе N лет назад, свеженькая и зелёненькая, пришла из Универа в НИИ писать диссер, первая я же вещь, от которой я сильно прибалдела, это то, как хорошо люди, чья профессия (ну, официально-то) не программирование, шарят в языках и технологиях. Тут были и С/С++, и Python, и Matlab, и Julia, и R (но, по-честноку, на крестах писалось и пишется 2/3 всего кода, а остальное, по моим глазомерным прикидкам, составляет всего 1/3), для работы на серверах использовались bash и perl, а до кучи к этому мои коллеги знали и были готовы с интересом обсудить за чашкой кофе кучу прочего, казалось бы, совсем не связанного: SQL и noSQL БД, html/php/JavaScript/CSS, bf и кучу всего ещё. Так же в «джентельменский набор» уважаемого коллегами сотрудника лаборатории входило знание основных паттернов программирования и основ вычислений на GPU (или, программа минимум — запуска своей программы в несколько процессов на нескольких ЦПУ). Крутым качеством считалось умение написать «самодокументированный» поддерживаемый код (хотя писать комменты многие мои коллеги крайне не любят и представление о «самодокументированности» у них бывает несколько завышенным. что уж там, мне тоже мои программы кажутся кристально ясными и без всяких комментов… где-то первые два дня после написания, а потом я радуюсь, что комменты я всё-таки оставила ;)) ).
Причины тому были достаточно просты:
- расчёты действительно бывают очень «тяжёлыми», для среднестатистического ноута — практически неподъемными, по крайней мере, у те сроки, в которые зачастую надо решить задачу. Поэтому они запускаются на больших вычислительных фермах. И хотя в наше время проблема вычислительного времени, пожалуй, не стоит так остро, как в какие-нибудь 80-е, но таки прождав в очереди на выполнение часов 6, вылететь из неё с segfault'ом (из-за неграмотной работы с памятью) за 10 секунд и потом стоять ещё сколько же, чтобы перезапустить — удовольствие сомнительное. А ещё более сомнительное удовольствие — это узнать, что ты стоял в очереди 6 часов, а не 10 минут, потому что некий твой коллега безответственно закушал себе целое лезвие на 48 потоков (про скопипастил чей-то чужой запускающий скрипт, например), а программу на выполнение поставил однопоточную, ибо строчку #pragma omp parallel for на своём самом верхнем самом тяжёлом цикле ниасилил.
- не знаю, как у вас в Донецке, а з/п среднеститистического российского учёного заставляет его вертеться, как белка в колесе (а то если будешь умным бедным, поди докажи кому, что ты правда умный :) ). Поскольку значительное количество рабочего времени ты пишешь код, отсюда логическим образом вытекает тот факт, что многие учёные предпочитают научиться программированию всерьёз и подрабатывать этим в свободное от работы время (насколько я заметила, мои зарубежные коллеги тоже так часто делают). Т.е., в некоторой степени по крайней мере треть моих знакомых из научного сообщества — профессиональные программисты (которые основную часть времени занимаются наукой «для души», а основной доход имеют к фриланса. Да, немного странно и весьма печально, но факт).
В вашей статье я заметила определённое количество бед, связанных с организацией рабочего процесса в организации (что-то имеет место и у нас):
- Отсуствие ТЗ. Воистину, программист в науке иногда — сам себе бизнес-аналитик. Встречаются крутые начальники, которые могут таки объяснить, чего они хотят и как, но, вообще говоря, во основном встречается ситуация, когда твой начальник — это твой заказчик и твоя первейшая задача — это формализовать размытые требования и самому себе это ТЗ составить. Минусы — хочется готовых ответов, а тут приходится самому поднапрячься. Плюсы: нет или почти нет «испорченного телефона» между заказчиком и разработчиком;
Код никто не защищает от неправильного ввода и нет никакого UX.
Одним из первых моих действий после освоения «джентельменского набора» стало прослушивание курса по UX. В ускоренной перемотке, и, имхо, там было многовато воды. Но пару адекватных мыслей я оттуда выхватила и стараюсь применять. Суть в том, что все мы люди, и удобный API, а иногда и UI — это то, что делает твою программу более популярной (если ты пишешь «долгострой» — библиотеку или фреймворк, который будет достаточно часто использоваться другими, как в моём случае) и может заставить людей ссылаться на твои статьи почаще, например. И да, от сложных «нелюдских» интерфейсов, которые в legacy коде приходится видеть во множестве, быстро начинается головная боль, вспоминается куча обсценной лексики, и приходит понимание того, что ты просто не хочешь писать код, который будет заставлять людей страдать;Большая часть кода будет использоваться один, или два раза.
«Нет ничего более постоянного, чем временное». Вот вы сколько раз запускали каждую программу как минимум для того, чтобы отладить? А когда вы докрутите какой-нибудь новый параметр в вашей системе, вы заново весь код для получения новых картинок преписывать будете? Или «макаронный код» наплодите? Или вы больше никогда не будете решать уравнения численно и возвращаться к этому коду, чтобы «подглядеть» свой собственный опыт?если студент делает некий расчёт <...> код почти никогда не абстрактен, и в нём может повстречаться костыль любого вида и размера.
А вы-то тут причём? Я встречала очень разных студентов — кто-то на третьем курсе имел опыт стажировки в Google, а кто-то, ниасилив цикл while, запускал подсчёт на 1000 итераций, в надежде, что оно за столько-то шагов точно сойдётся. Задача научрука — учить студента уму-разуму, передавать знания. Задача студента — учиться, и не только решать уравнения, но и жизни. Например, принимать ответственность за собственные косяки и самостоятельно исправлять их.
Я вообще не очень поняла эту тенденцию наезда на языки. Если я прощёлкала клювом и у меня память течёт, то это я прощёлкала клювом, сейчас пофиксим. Если студент лажает и не знает, где в Интернете StackOverflow — то я ему тактично разъясню. Но с языка-то какой спрос, если он Тьюринг-полный? Моя бабушка, вон, до сих пор с придыханием вспоминает тот момент, когда появился ассемблер и прогать стало, как два пальца от асфальт. А то в машинных кодах, конечно, тоже весело было, но сильно медленнее.- Я не решала уравнения Рунге-Кутты где-то с института (где в учебных целях заставляли писать всё from scratch), и не думаю, что могу дать хороший совет в том, как это лучше делать. Но при том, что это стандартная лаба по численным методам где-то за 3-ий курс, я подозреваю, что подключаемых библиотек с простым интерфейсом, которые могут порешать это за вас, должно быть достаточно. Искать можно здесь, в гугле, и сразу на mathoverflow. Успехов!
- Есть такой грустный момент во многих научных организациях, который роднит их с бизнесом. А именно то, что код редко всерьёз покрывается тестами, а про CI остаётся только мечтать. История и там, и там одинаковая: над работником умственного труда стоит дядя или тётя-управленец и вещает: «Чего ты мне тут юнит-тесты пилишь! Это же просто лишний код, а у нас времени нет! Ты не баги фикси, а фичи выдавай!» И это боль, да.
Итого: работа в науке имеет свои специфические горести и радости, а ещё содержит в себе кучу палок о двух концах. Например, само слово «учёный» подразумевает человека, который много чего изучает, учит. Например, высшую математику, как свой рабочий инструмент (хотя он, может, и не профессиональный математик), или программирование (хотя и не программист) или, например, основы геологии (подставьте сюда любую науку, которая не ваша), если коллеги из соседнего НИИ просят помочь с расчётами. Даже с CMS'ами и кастомным довёрстыванием сайтов иногда, ведь нужны же вашим проектам сайты, а денег нет. Короче, разбираться приходится быстро, чёрт пойми в чём, и чем качественнее, тем лучше. С одной стороны — напряжно, с другой — весело и всё время что-то новое. За последнее, как я подозреваю, мы и любим эту работу и стараемся в ней профессионально расти.
И спасибо создателям языком программирования и библиотек для научных вычислений за то, что облегчают наш труд, а местами в принципе делают его возможным.
P.S. Как сказала мне ещё в студенчестве одна мудрая пожилая доктор наук: «Тебе что, не пофиг на каком языке программировать? Взяла методичку и вперёд!»
Тут были и С/С++, и Python, и Matlab, и Julia, и R
Очень странно слышать. Либо научная группа которая занимается в основном численными расчётами. В моём окружении такой человек один на 6-8 (среди тех кто занимается наукой, без учёта тех кто фрилансит, а это половина). Экспериментальщики чаще доверяют установкам, теоретики — бумаге. Т.е. должна быть группа которая вся целиком занималась бы симуляциями — тогда в ней можно было бы вести такие разговоры. Но по-моему больше всех всё-таки смешанных групп, где один-два занимаются моделированием. И на втором месте чистые группы из экспериментаоров. И это статистика не по стране, а скорее общемировая — у англичан и поляков экспериментаторов тоже везде больше всех.
расчёты действительно бывают очень «тяжёлыми»
Ну так в этом и искусство. Часть решить аналитически, часть не учитывать, и так далее.
Поскольку значительное количество рабочего времени ты пишешь код
Вот это подтверждает мою версию, что у вас очень спецефичная группа. Обычно значительную часть времени занимают обсуждения, анализ, чтение свеженьких статей, и так далее. Если говорить о часте работы именно в исследовании — то анализ обычно дольше написания кода. Вернее как-то так происходит, что обсуждается новый график 2 часа, в итоге идём на другой этаж к эксприментатору который что-то такое делал, спрашиваем — а сколько там вообще атомов в кластере такого типа бывает, ещё 4 часа обсуждения ситуации и какой именно кластер, и какие условия зарождения, в итоге получаем одну единственную цифру, возвращаемся, вбиваем эту одну цифру и ещё пару строк кода. Оставляем на ночь считать. Утром красота, вискеры заколосились. Только визуализацию на фото наложи. Т.е. в итоге-то написание кода довольно крошечную часть времени занимает. Даже если с нуля писать, как ни странно.
и приходит понимание того, что ты просто не хочешь писать код, который будет заставлять людей страдать;
Я абсолютно согласен. К сожалению, иногда и в офисах IT компаний пишут такой код.
Но иногда код — это действительно одноразовый инструмент.
«Нет ничего более постоянного, чем временное». Вот вы сколько раз запускали каждую программу как минимум для того, чтобы отладить? А когда вы докрутите какой-нибудь новый параметр в вашей системе, вы заново весь код для получения новых картинок преписывать будете? Или «макаронный код» наплодите? Или вы больше никогда не будете решать уравнения численно и возвращаться к этому коду, чтобы «подглядеть» свой собственный опыт?
Один из лучших умов, что я знаю, пишет макаронный код в виде страниц текста «по ширине», с готу и прочим. Он при мне мгновенно сориентировался в своём диком коде и дописал фичу спустя десять лет после написания. Наша с ним общая черта — нам всем легко разбираться в своём коде, даже если он супер-нечитабелен.
А вы-то тут причём?
Это не при чём) Это к разным относилось частям.
лаба по численным методам где-то за 3-ий курс, я подозреваю, что подключаемых библиотек с простым интерфейсом, которые могут порешать это за вас, должно быть достаточно
Только если коэффициенты не пересчитываются на ходу методом стрельбы. Это трёхвложенный цикл решающий две зависимые системы уравнений. Слишком особый случай. Именно для таких и нужно умение писать программы, иначе всё бы на листах маткада делалось бы…
А именно то, что код редко всерьёз покрывается тестами
Тесты должны знать что должно получится. Симуляции пишутся, когда не вполне уверен что должно получится — но есть не менее двух ожидаемых результатов, которые подтвердят теорию/корректность модели, либо нет.
«Две зависимые системы уравнений» называются просто «система уравнений».
Нет, ну есть факторизация. Которая развязывает системы. И они могут относится к разной природе. Их можно назвать «система уравнений, описывающая систему», но это не несёт никакой дополнительной информации. Лучше говорить отдельно о системе для параметра К, и об общей системе, которая описывает, к примеру, фазовый портрет всего происходящего, ну а К в ней фигурирует уже как зависимый параметр
.
.
То, что вы часть уравнений обозвали одной системой, а часть другой, никак не влияет на алгоритм. С точки зрения алгоритма решения системы уравнений это по-прежнему одна система уравнений.
С точки зрения алгоритма — я могу решать их двумя разными методами, с разным типом начальных условий, и с разной собственной точностью, если это будет оправдано.
Это вообще как?
Я уже приводил такой пример где-то в комментариях:
dT_f/dT = f(T_f, T, h(T_f))*g(d(T_f/T)/dT), T_0=9000, T_f_0=9000
нужен Рунге-Кутты, с шагом по Т (величина шага скажется на точности)
(dh(t_f)/dt)|_(t=inf) = a*T_f + I(T, h), h_0 = 16
нужен метод стрельбы, перебор в цикле метода Рунге-Кутты, с отслеживанием изменения асимптотики на больших t, шаг внутренний — по h внешний, по производной от h. Тоже дадут другую погрешность. Просто потому что оличаются доступные начальные данные для двух уравнений.
dT_f/dT = f(T_f, T, h(T_f))*g(d(T_f/T)/dT), T_0=9000, T_f_0=9000
нужен Рунге-Кутты, с шагом по Т (величина шага скажется на точности)
(dh(t_f)/dt)|_(t=inf) = a*T_f + I(T, h), h_0 = 16
нужен метод стрельбы, перебор в цикле метода Рунге-Кутты, с отслеживанием изменения асимптотики на больших t, шаг внутренний — по h внешний, по производной от h. Тоже дадут другую погрешность. Просто потому что оличаются доступные начальные данные для двух уравнений.
Полностью ваших обозначений я не понял, но выглядит так, как будто достаточно одного только метода стрельбы.
Подумал пару дней, но так и не придумал как это сделать. Поменять местами циклы переборов можно, но производительность тогда только упадёт, поскольку неизвестное (но большое) число раз отрабатывает подбор начальной производной для стрельбы, и размещая дифференциальный прирост функции внутри него мы будем расчитывать её заведомо большее число раз. А если вынести обратно только функцию пересчёта дифференциала на шаге, чтобы этого избежать, то мы приходим к моему методу, где по сути отдельно идёт решение обычным РК, и на каждом его шаге отрабатывает стрельба.
То, что вы часть уравнений обозвали одной системой, а часть другой, никак не влияет на алгоритм. С точки зрения алгоритма решения системы уравнений это по-прежнему одна система уравнений.
Не в контексте обсуждения, но в качестве примера: представьте себе что у вас есть некая система линейных уравнений. Получаемое в этой системе решение затем (ну, задача такая) используется для построения другой системы линейных уравнений (к примеру, решение первой системы есть правая часть второй системы). С формальной точки зрения эти две системы линейных уравнений объединяются в одну систему уравнений, однако для алгоритма, который для заданной матрицы и правой части решает СЛУ это будут две разные системы уравнений.
Ну и приведу сразу реальный пример подобного:
ru.wikipedia.org/wiki/LU-%D1%80%D0%B0%D0%B7%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
Раздел «Решение систем линейных уравнений»
Для нахождения решения задачи необходим лишь алгоритм, который решает СЛУ с треугольной матрицей. Этот алгоритм применяется два раза для каждой задачи (задачи отличаются правой частью). Так что да, иногда
То, что вы часть уравнений обозвали одной системой, а часть другой, как-то влияет на алгоритм.
У вас после разбиения уравнения на два все упростилось, так можно делать. А у автора разбиение на две части служит оправданием для усложненного кода — вот что странно.
Нет, у него там написано что он не может использовать чужую библиотеку из-за того, что у него параметры численного метода меняются. Он использует численный метод, у которого (при описании в учебниках) есть постоянный параметр: шаг. Т.е. в доступных реализациях интерфейс выглядит а-ля
applyRungeKuttaMethod(<...>, step=1.0, <...>)Экспериментальщики чаще доверяют установкам, теоретики — бумаге.
Вы как себе физический эксперимент представляете? Типа, спаял установку, нажал большую красную кнопку, подождал годик, а потом — бац! — открытие? Да если бы… Данные надо анализировать (на данный момент, для этого нужны люди, причём очень много очень умных людей), под анализом я имею в виду историю про восстановление спектров масс, определение углов смешивания и прочие чудесные вещи, для извлечения которых вам нужно писать какой-то код, а не просто с задумчивым лицом рассматривать график. Данных очень много (миллионы собтытий, гигабайты логов), а всякие классные штуки типа QCD — очень сложные и тяжёлые. На бумажке с ручкой их уже профессиональные математики упростили до максимума. И это всё равно часы работы для суперкомпьютера.
А у теоретиков — куча своего специфического ПО. Давно не видела хорошего теоретика, который работал бы вообще голыми руками, не используя ну хотя бы Matlab вместо карманного калькулятора.
Один из лучших умов, что я знаю, пишет макаронный код
Очень хочется верить, что это действительно классный учёный. Я знаю сколько-то «великих дедов», которые даже уже и не пишут, но при их научной прозорливости, оно им и не надо, их задача — делиться мудростью. Однажды, возможно, лучшие из нас смогут достичь их уровня понимания законов Вселенной. К несчастью, я на практике заметила, что некоторые люди, пишущие непонятный код, склонны считать себя «великими умами» именно из-за непонятности своего кода и всюду этим хвастаться. Вот это уже нельзя назвать примером для подражания.
Тесты должны знать что должно получится.
Есть такая штука — юнит-тесты. Это когда тестируешь маленькие кусочки своего кода, например, функции, на то, правильно ли они работают. Чтобы потом не случалось печальных историй по типу тех, о которых ещё один наш коллега выше рассказывал, когда «считали 2 года на суперкомпьютере, потом нашли ошибку в формуле, и весь результат пошёл коту под хвост». Не путайте с приёмочными тестами, это другое.
Вот это подтверждает мою версию, что у вас очень спецефичная группа. Обычно значительную часть времени занимают обсуждения, анализ, чтение свеженьких статей, и так далее.«Значительный» != «весь». Это относительная речевая формулировка. А то скажете ещё, что я статей не читаю :)). Или что обсуждение алгоритма вашей программы с группой не является частью её написания (программисты точно обалдеют, а менеджеры побегут срезать им з/п за то время, пока они у доски с маркерами формулы рисуют от лентяйства :) ).
для извлечения которых вам нужно писать какой-то код, а не просто с задумчивым лицом рассматривать график.
На самом деле в большинстве случаев — нет. Дело в том что экспериментальные установки покупаются вместе с софтом, который ими оперирует. И очень много где в статьи попадают картинки, который этот стандартный софт и выдаёт. То есть у экспериментатора под рукой: установка, софт для неё, программа для визуализации данных (в которой часто кроме графика, можно сразу же глянуть график производной, или вписать формулу для обработки, как в экселе).Опять таки, это может быть selection bias, но по моему опыту общения — 3 из 32 экспериментальщиков программируют (за пределами обычных пакетов вроде маткада и базовых фич матлаба/мэпла). И двое как раз из тех, кто делает новые экспериментальные установки.
К несчастью, я на практике заметила, что некоторые люди, пишущие непонятный код, склонны считать себя «великими умами» именно из-за непонятности своего кода и всюду этим хвастаться.
Да это тоже самое, что гордиться плохим почерком =)
А человек тот из слегка другой категории. Просто изобретатель и открыватель. Он почти не анализирует, просто делает то, что раньше никому не удавалось.
Не путайте с приёмочными тестами, это другое.
ОК, просто юнит тесты должны покрывать какие-то осмысленно выделенные куски, например функции. А когда есть две-три функции, и простыня вычислений в каждой, то сложно покрыть такой код тестами.
Не хотел обидеть, просто имел ввиду что программирование может занимать и небольшую нишу, даже в исследовании с численным моделированием.
Поясните пожалуйста, возможностей математических пакетов, типа maple, mathematica все еще не хватает для математических расчетов? Для чего писать код вручную?
В данном случае, наверное, не было смысла, но вообще иногда бывает, что выходит слишком медленно. Кроме того бывает, что расчёты интегрируются в программный пакет и тогда тянуть maple/mathematica неудобно/не имеет смысла.
Использование двух разных методов для внешнего уравнения и внутренней системы, например. maple, mathematica — почти нереально это сделать. matlab теоретически такое умеет, но писать это там будет лишь немногим легче, чем в экселе. Для такого расчёта, (да и вообще для расчёта достаточно сложного диффура) лучше самому набросать код.
Эти пакеты многое решают, но всегда найдётся область, слегка выпирающая за пределы их функционала.
Иногда специализированный пакет расчитывает поле, а поведение частицы в полученном поле — уже дописывается от руки, иногда другие гибриды возникают.
Эти пакеты многое решают, но всегда найдётся область, слегка выпирающая за пределы их функционала.
Иногда специализированный пакет расчитывает поле, а поведение частицы в полученном поле — уже дописывается от руки, иногда другие гибриды возникают.
Это только мне кажется, что программисты на С++ смешивают знание синтаксиса языка и знание библиотек? Мне всегда казалось, что это довольно далекие понятия. И именно тот факт, что на С++ сейчас нельзя (ну, или очень сложно) писать нормальные программы без использования хотя бы стандартной библиотеки, а в ней сплошь и рядом совершенно неудобочитаемые названия, приводит к высокому порогу вхождения в программирование на С++. Автор же явно указал, что тот, кто писал программу, знал синтаксис языка, а не библиотеки.
Вообще, я думаю, что развитие С++ пошло куда-то не туда: на заре язык был мощным и удобным в использовании, программы получались короткими и читаемыми. А потом все (в первую очередь те, кто делает библиотеки) забыли об удобстве пользователей. И вместо простого цикла (int i — что может быть короче?) или выделения памяти (s* sp=new s, опять же, коротко и ясно) появились монструозные (хотя и безопасные в использовании) конструкции. Возможно, их стоило бы сразу же спрятать (причем очень хорошо спрятать — чтобы они не вылезали ни в сообщениях об ошибках компилятора, ни в консольных отладчиках) — и это бы само по себе облегчило новичкам изучение языка. А так — имеем то, что имеем.
Вообще, я думаю, что развитие С++ пошло куда-то не туда: на заре язык был мощным и удобным в использовании, программы получались короткими и читаемыми. А потом все (в первую очередь те, кто делает библиотеки) забыли об удобстве пользователей. И вместо простого цикла (int i — что может быть короче?) или выделения памяти (s* sp=new s, опять же, коротко и ясно) появились монструозные (хотя и безопасные в использовании) конструкции. Возможно, их стоило бы сразу же спрятать (причем очень хорошо спрятать — чтобы они не вылезали ни в сообщениях об ошибках компилятора, ни в консольных отладчиках) — и это бы само по себе облегчило новичкам изучение языка. А так — имеем то, что имеем.
Автор же явно указал, что тот, кто писал программу, знал синтаксис языка, а не библиотеки.Вообще автор ничего толком не указал, мы так и не знаем, в чём были проблемы. Можно однако предположить, что автор знал стандартную библиотеку Python, но не сумел воспользоваться оной в C++/Delphi.
Мне показалось, что автор как раз весьма подробно рассказал и о том, как выглядела проблема (программа забирала себе все ресурсы, до которых могла дотянуться, выделяла себе памяти раз так в 10 больше физической RAM в системе, и из-за этого все начинало тормозить так, что оставалось только вырубить компьютер, если он еще раньше не падал сам оттого, что не мог вовремя обработать какую-нибудь срочную задачу — не знаю, получится ли устроить такое на свежих ОС, а раньше получалось легко и на ура), и о том, в чем она на самом деле состояла (в некоторой области значений программе не хватало ни float, ни double, ни какой другой арифметики с заранее заданной шириной — а язык — без сторонних библиотек, из коробки — не умеет работать с числами с динамически расширяемой разрядностью, из-за этого программа проскакивала область экстремума и уходила в область, где метод расходился — а среда выполнения при этом не обеспечивала — из коробки и общеизвестного, опять же — автоостанова по превышению предела использования памяти). В общем, наверное, в С++ все решалось бы наличием общеизвестной или хотя бы достаточно популярной (так, чтобы ее не надо было искать, а достаточно было вспомнить главу из учебника, например) библиотеки, работающей с такими числами. И общепринятой практикой ограничивать ресурсы, запуская программу. Но в итоге оказалось проще выбрать интерпретатор, который делает это за пользователя, а не искать способы реализации первого на С++ и настройки второго в Windows XP.
Выглядит разумным подходом для пользователя, которому нужно получить однократный результат, а завтра заняться чем-то совсем другим.
Конечно, если подобные вычисления надо проводить постоянно, то выигрыш в скорости в конце концов окупит время на поиск библиотеки и изучение администрирования Windows. Но при разнородных задачах проще выбирать вариант, где большинство граблей уже убрано. Или и не появлялось никогда.
Я, кстати, в последнее время тоже предпочитаю в начале работы с какой-нибудь новой микросхемой подергать ее с помощью Embedded JS или MicroPython. А уже потом писать нормальную программу на С или С++. Так выходит быстрее — система не падает, интерпретатор выдает вменяемые сообщения об ошибках, и в любой момент можно что-то вызвать вручную. А уже потом, когда понятно, как оно работает и чего от него ждать, можно писать полноценную программу.
Выглядит разумным подходом для пользователя, которому нужно получить однократный результат, а завтра заняться чем-то совсем другим.
Конечно, если подобные вычисления надо проводить постоянно, то выигрыш в скорости в конце концов окупит время на поиск библиотеки и изучение администрирования Windows. Но при разнородных задачах проще выбирать вариант, где большинство граблей уже убрано. Или и не появлялось никогда.
Я, кстати, в последнее время тоже предпочитаю в начале работы с какой-нибудь новой микросхемой подергать ее с помощью Embedded JS или MicroPython. А уже потом писать нормальную программу на С или С++. Так выходит быстрее — система не падает, интерпретатор выдает вменяемые сообщения об ошибках, и в любой момент можно что-то вызвать вручную. А уже потом, когда понятно, как оно работает и чего от него ждать, можно писать полноценную программу.
выбрать интерпретатор, который делает это за пользователяНа сколько мне известно, Python не делает это за пользователя. Ну и вопрос о том, на сколько опыт автора репрезентативен остается открытым. Совершенно не показано, что его удача с Python — это закономерность, а не случайное стечение обстоятельств.
Полностью согласен. Более того, из статьи следует, что дело как раз в удачном стечении обстоятельств.
Но вот, возникает ощущение, что для непрофессионального программиста обстоятельства будут чаще складываться удачно именно при использовании Python (а не Pascal или, тем более, С++) — у него песочница лучше.
И, когда оглядываюсь вокруг, это ощущение усиливается.
Я собственно, не так уж давно это осознал. Потому и статья зацепила.
Но вот, возникает ощущение, что для непрофессионального программиста обстоятельства будут чаще складываться удачно именно при использовании Python (а не Pascal или, тем более, С++) — у него песочница лучше.
И, когда оглядываюсь вокруг, это ощущение усиливается.
Я собственно, не так уж давно это осознал. Потому и статья зацепила.
UFO just landed and posted this here
Например, на С. И на С++. Периодически этим занимаюсь на работе, когда микроконтроллеры программирую. Да, в общем, много где можно. Когда-то в прошлом веке принимал участие в разработке компилятора С++ — так его тоже, в общем, почти без библиотек делали (ну, то есть, вызовы read и write, конечно, брали готовые — хотя, в принципе, ничто не мешало сделать прямой системный вызов и избавиться от библиотек вообще). Что ядро Линукса, что загрузчики всякие тоже не особо стандартые библиотеки используют. А программы, в общем, вполне нормальные.
UFO just landed and posted this here
:)
Спасибо.
В общем, в данном контексте получились ключевыми слова «сейчас» и «или очень сложно» — все же ядро Linux не самая новая разработка, да и компилятор я писал лет 20 назад.
Я совсем не призываю обходиться без сторонних библиотек (хотя это и остается моим любимым занятием — но мир меняется, да и таких мамонтов, как я, мало осталось). Но нужны удобные языки, удобные среды исполнения, удобные библиотеки — чтобы снижался порог вхождения, чтобы все удобно читалось и легко писалось.
Думаю, что выскажу крамольную мысль — но возможно, идеальная стандартная библиотека для С++ должна делать из него что-то, подобное JS. Ну, или Python. Возможности языка это вполне позволяют.
Вот тогда и новые программисты будут в сообщество приходить, и ученым станет удобно языком пользоваться… А потом уже кто-то из них заглянет внутрь и постепенно начнет использовать остальные возможности языка.
Спасибо.
В общем, в данном контексте получились ключевыми слова «сейчас» и «или очень сложно» — все же ядро Linux не самая новая разработка, да и компилятор я писал лет 20 назад.
Я совсем не призываю обходиться без сторонних библиотек (хотя это и остается моим любимым занятием — но мир меняется, да и таких мамонтов, как я, мало осталось). Но нужны удобные языки, удобные среды исполнения, удобные библиотеки — чтобы снижался порог вхождения, чтобы все удобно читалось и легко писалось.
Думаю, что выскажу крамольную мысль — но возможно, идеальная стандартная библиотека для С++ должна делать из него что-то, подобное JS. Ну, или Python. Возможности языка это вполне позволяют.
Вот тогда и новые программисты будут в сообщество приходить, и ученым станет удобно языком пользоваться… А потом уже кто-то из них заглянет внутрь и постепенно начнет использовать остальные возможности языка.
UFO just landed and posted this here
Так валидный код 20-летней давности без библиотек скомпилируется и сейчас
Лет 10 назад компилировался. Потом не проверял.
Мне-то проще, чем другим, без сторонних библиотек код писать — у меня все свои :) Когда-то и TCP/IP стек делал, и беспроводные протоколы, и Fat32 на карточках, и ОС свою, и в ядре Линукса много ковырялся… И еще кучу всего.
Не надо из плюсов делать JS или Python, для этого уже есть JS или Python. Лучше всё-таки специализированными инструментами пользоваться, и для научных вычислений таковые есть получше, чем Python.
С одной стороны, это так. С другой — чем больше людей поддерживают какую-то технологию, и (это, наверное, даже важнее) чем больше приходит новых людей, тем лучше и быстрее она развивается. Специализированные инструменты знают (по сравнению с Python) немногие. Поэтому они медленнее развиваются. И не становятся достаточно универсальными для научных задач (а они часто достаточно разнородны — сегодня надо систему дифуров решать, а завтра — картинку фильтрами обрабатывать). И поэтому многие мои знакомые из науки уже тоже перешли на Python.
С плюсами — та же проблема. Из-за их сложности многие учат JS или Python. И плюсы вообще остаются сбоку. Из-за чего хиреют и умирают. До конца, конечно, еще далеко. Но процесс, кажется, уже пошел — новых программистов на плюсах, по моим ощущениям, все меньше. Вот и я уже дочек учу писать на JS и Python…
Мне кажется, какая-то библиотека, позволяющая писать код в стиле интерпретируемых языков без типизации, достаточно мощная (чтобы код мог быть универсальным), обеспечивающая песочницу для кода, и в то же время позволяющая при необходимости (или при желании) добавлять в программу элементы «настоящего» С++ (прямо в текст 10-строчной программы в стиле JS, без большого порога, опять же) позволила бы увеличить популярность плюсов и обеспечить их развитие.
Хотя, по моим ощущениям, поезд уже ушел. И таймер тикает.
UFO just landed and posted this here
на плюсах решать очень тяжело и больно, но на питоне их решать ещё тяжелее и больнееУ меня аналогичный опыт. Но Python универсальнее R, потому я бы стат анализ тоже на Python писал, что бы не плодить сущности :). Мне кажется, всё, что не стОит писать на Python, — нужно писать на C++. Ну то есть пара C++/Python покрывает всё что можно покрыть. Если бы только у Python нормальная типизация была, хотя бы как у C… Хотя языки типа Rust или Haskell моглибы прийти на замену этой паре. Но из «старых» языков, по гамбургскому счету, составить конкуренцию паре Python/C++ никто не в состоянии, имхо. Распространённость Java/C#/Go/PHP/JavaScript, имхо связанна с тем, что Python не достаточно рано набрал обороты и с агрессивным маркетингом NIH-синдромных продуктов (то есть дотациями). И несмотря на все предыдущие дотации, без новых дотаций оно имхо пошло бы на спад.
А для C++ не хватает 1) модулей, 2) нормального compile-time языка вместо шаблонов и 3) рефлексии (следсвие 2). При чём модули сами по себе не особо помогут, проблема в том, что для C++ не существует нормальной инфраструктуры для сборки и установки пакетов и библиотек типа PyPI. И модули эту задачу не решат. CMake ужасен, но и на том спасибо.
P.S. Сорри что встреваю.
UFO just landed and posted this here
каждой задаче свой инструментДа, но только если специализированный инструмент существенно лучше для своей задачи чем универсальный. В случае с R, для тех задач, с которыми я сталкивался, преимущества над Python незначительные.
Почему компилятор бы не стали писать на плюсах? Правда интересно. Конечно strong static лучше. Но типизация C не то что бы «слабее» Python-вской, или нет? Я не сильно успел с Rust познакомится, но мне понравилось что переменные const by default.
А как тырпрайз решил? emerge/pacman хватает, если софт не cross-platform, а иначе боль. На некоторых платформах вообще нормальной системы пакетов нет (windows, android, про iOS не знаю, maxOS с натяжкой) Да и даже так, если хочешь использовать не совсем мейнстримную либу — приходится мучатся со сборкой, бывает.
То ОС падает от ошибок в алгоритме, то лапы ломит, то хвост отваливается(с)
Давно такой чуши не читал. Ведь во всём виноват С++.
Ну это за гранью
Давно такой чуши не читал. Ведь во всём виноват С++.
Код на винде, по крайней мере, может залезть в область памяти с кодом ОС, и крашнет её.
Ну это за гранью
Чисто ради спортивного интереса выкладываю одну из подзадач в простейшем виде
исходные значения:
x = 0.53
q=31900
da=2
t=900
tf=900
a=100000
b=0.5
tau=1.03E-23
уравнение для нужной величины:
dtf/dt = tf*(1-tf/t)*b*(((a)*tau)**(-b))*(exp(-b*(x)*q/t))*(exp((x-1)*b*q/tf))*(t**(b-1))
где а проседает на da c каждым шагом по времени, при прямом процессе охлаждения, и растёт на обратном пути при нагреве. Температура t должна опуститься до нуля, затем подняться назад. Нужно вывести значения tf, tf-t, производной и разницу tf на двух ветках гистерезиса на графиках, найти экстремумы, в процессе расчёта выкидывать сообщения о смене направления процесса, и о прохождении точек экстремума и перегиба, с возможностью менять шаг после их прохождения.
Если сделать сейчас эту задачу на разных языках, то специалист (каждый в своём) сможет замерить время разработки, время выполнения и размер кода. (для чистоты эксперимента в двух видах — с использованием известных библиотек и сторонних модулей, и без них — поскольку в комментариях было мнение ещё про большую завязанность C на библиотеках (с чем я соглашаюсь, т.к. собственных возможностей языку оставили значительно меньше, чем многим другим))
исходные значения:
x = 0.53
q=31900
da=2
t=900
tf=900
a=100000
b=0.5
tau=1.03E-23
уравнение для нужной величины:
dtf/dt = tf*(1-tf/t)*b*(((a)*tau)**(-b))*(exp(-b*(x)*q/t))*(exp((x-1)*b*q/tf))*(t**(b-1))
где а проседает на da c каждым шагом по времени, при прямом процессе охлаждения, и растёт на обратном пути при нагреве. Температура t должна опуститься до нуля, затем подняться назад. Нужно вывести значения tf, tf-t, производной и разницу tf на двух ветках гистерезиса на графиках, найти экстремумы, в процессе расчёта выкидывать сообщения о смене направления процесса, и о прохождении точек экстремума и перегиба, с возможностью менять шаг после их прохождения.
Если сделать сейчас эту задачу на разных языках, то специалист (каждый в своём) сможет замерить время разработки, время выполнения и размер кода. (для чистоты эксперимента в двух видах — с использованием известных библиотек и сторонних модулей, и без них — поскольку в комментариях было мнение ещё про большую завязанность C на библиотеках (с чем я соглашаюсь, т.к. собственных возможностей языку оставили значительно меньше, чем многим другим))
Зачем переусложнение? Например, всё вот это: b*(((a)*tau)**(-b)) — в вашем численном интегрировании является константой.
Итого ваш дифур выглядит как:
dy/dt = С * y * (1 — y/t) * exp(-A/t) * exp(B/y) * t^d
tf я переобозначил как y, потому что читать выражения типа dtf/dt сложно, а A, B, C и d — константы в рамках вашего интегрирования.
А, простите, прочитал: a не константа, а меняется с температурой. А где здесь время? Вы пишете, что a меняется со временем, но при этом t — это не время, а температура. Где же время?
Итого ваш дифур выглядит как:
dy/dt = С * y * (1 — y/t) * exp(-A/t) * exp(B/y) * t^d
tf я переобозначил как y, потому что читать выражения типа dtf/dt сложно, а A, B, C и d — константы в рамках вашего интегрирования.
А, простите, прочитал: a не константа, а меняется с температурой. А где здесь время? Вы пишете, что a меняется со временем, но при этом t — это не время, а температура. Где же время?
Я указал что идёт охлаждение, а затем нагрев. Значит температура прямо зависит от времени.
b и прочее — это задел на будущее, когда их понадобится поменять для других процессов/материалов.
b и прочее — это задел на будущее, когда их понадобится поменять для других процессов/материалов.
Вы в обсуждении выше кучу раз писали что ваш код — одноразовый. Откуда в одноразовом коде появился задел на будущее?
Ну он отработает один раз. Подвергнется некоторым переделкам, чтобы немого другое посмотреть. Затем запустится существенно другой код, тоже один раз. Всего, кусок кода с уравнением, может быть, запускался 8-10 раз. Но это, во-первых, всё равно счётное число раз. Во-вторых, каждая версия кода сильно отличается от предыдущей, хотя может содержать тот же метод и то же уравнение. Именно в этом и преимущество программирования — в готовом пакете можно как-то оформить в правильном виде функцию. Потом хочеться сделать один из её параметров варьируемым, или зависимым, и, скорее всего, придётся менять весь вид задания условий, и переписать с нуля весь блок символьных вычислений.
В программировании можно сделать проще, и использовать разрешающую часть кода снова, просто вмонтировав куда-нибудь во внутрений цикл строчку-две, или добавив ещё один. Нет никаких ограничений, как в матпакетах (матпакет бы ругнулся что в первой строке нужно указывать уравнение без у в правой части, после переписывания под этот каприз он бы сказал что больше трёх уравнений не принимает, потом становится понятно что переписать в более компактную систему с развязаными правыми частями не получается, и всё — надо помещать решение в цикл, и вручную дописывать логику выбора из двух-трёх систем… В итоге такой код в матпакете раздувается на несколько листов, и в нём гораздо проще запутаться).
Ну и если делать как принято у программистов — создавать программу и модифицировать её с помощью программы для контроля версий, тогда это был бы всё равно запуск одной программы. Но я так не делаю, поскольку было бы странно под одним названием но разными версиями хранить программы, которые считают разное. Проще хранить отдельно 10 файликов с частично повторяющимся кодом, но зато каждый из них будет иметь своё предназначение. Так что даже в конце работы над проблемой это будет 10 разных программ, абсолютно независимых, и без общих модулей. Так правильнее.
В программировании можно сделать проще, и использовать разрешающую часть кода снова, просто вмонтировав куда-нибудь во внутрений цикл строчку-две, или добавив ещё один. Нет никаких ограничений, как в матпакетах (матпакет бы ругнулся что в первой строке нужно указывать уравнение без у в правой части, после переписывания под этот каприз он бы сказал что больше трёх уравнений не принимает, потом становится понятно что переписать в более компактную систему с развязаными правыми частями не получается, и всё — надо помещать решение в цикл, и вручную дописывать логику выбора из двух-трёх систем… В итоге такой код в матпакете раздувается на несколько листов, и в нём гораздо проще запутаться).
Ну и если делать как принято у программистов — создавать программу и модифицировать её с помощью программы для контроля версий, тогда это был бы всё равно запуск одной программы. Но я так не делаю, поскольку было бы странно под одним названием но разными версиями хранить программы, которые считают разное. Проще хранить отдельно 10 файликов с частично повторяющимся кодом, но зато каждый из них будет иметь своё предназначение. Так что даже в конце работы над проблемой это будет 10 разных программ, абсолютно независимых, и без общих модулей. Так правильнее.
Неважно сколько там файликов и какие у них имена, это все равно повторное использование кода. То есть код не одноразовый.
Ну пусть 10-разовый (если учитывать копии с искажениями). Это не меняет подхода. Не должен будет этот код работать на сервере, чтобы его через апи 10000 пользователей в секунду дёргали. Я указал этот пункт в статье чтобы показать отличие от веб-программирования, где более существена скорость отработки, и заставлять пользователя ждать несколько часов неприемлимо. И от программирования встроенных систем, где необходима реакция в реальном времени, и обращения идут от одного компьютера 9600 раз в секунду. Там тоже так нельзя. А в научных — пфф, есть ещё время пока решаешь уравнения, проводишь эксперименты, читаешь статьи, дописываешь свои тексты, обсуждаешь с коллегами, посещаешь семинары, читаешь лекции, кушаешь и спишь. Исследования за один день не делаются (большая их часть).
Еще интересно было бы узнать, что это за множитель при скорости процесса:
(a * tau)^(-b)
τ в степени -b — это, конечно, константа, и в вычислительном аспекте её величина роли не играет. Однако же интересно, что это физически за величина и откуда у неё такое странное значение: τ = 1.03e-23. Такие масштабы встречаются редко, по порядку величины это почти что обратное число Авогадро, но не оно. В измерениях характеристик каких-то материалов это число вылезти может мало где из метрологических соображений.
(a * tau)^(-b)
τ в степени -b — это, конечно, константа, и в вычислительном аспекте её величина роли не играет. Однако же интересно, что это физически за величина и откуда у неё такое странное значение: τ = 1.03e-23. Такие масштабы встречаются редко, по порядку величины это почти что обратное число Авогадро, но не оно. В измерениях характеристик каких-то материалов это число вылезти может мало где из метрологических соображений.
т — нормировка для времени релаксации. Гипотетическое время, за которое релаксировала бы система, не изменяющая теплоту по этой модели. Немного отличается от нуля только потому, что 0 теплоты — это очень далеко от области применения модели. Но само время релаксации увеличивается экспоненциально с ростом потерь теплоты, поэтому коэффициент быстро достигает порядков вменяемого размера. Совпадение с порядком Авогадро случайно, т.к. коффициент имеет физический смысл интервала времени, и в реальном процессе полное время релаксации на очень много порядков больше (множитель для получения реального времени релаксации меняется в зависимости от начальных условий и материала от 10^21 до 10^35)
… интереса выкладываю одну из подзадач в простейшем видеИнтервалы времени пропущены?
Если уж сравнивать покажите кусок вашей реализации, что б перевести на другой язык и сравнить время.
Читал статью, удивлялся, снова читал, снова удивлялся, дочитал. Вспомнились шуточки про UK scientist:
Ученые открыли питон!
Ученые выяснили, что питон проще чем Си!
Ученые открыли питон!
Ученые выяснили, что питон проще чем Си!
Строго говоря, мне неоднократно приходилось править вылетающий чужой расчетный код на Delphi именно из-за неаккуратной работы с памятью. В поведении с динамическими массивами Delphi почти ничем не отличается от C++, кстати проверка границ работает только для статических массивов и выполняется ЕМНИП только на этапе компиляции, в рантайме можно легко напороться и на use after free и на вылет за границы.
Python не очень хорош, т.к. быстро работающие расчётные библиотеки тоже могут иметь свои протекающие абстракции и взрывы из-за недостатка точности etc. Но с другой стороны, ученые уже к нему привыкли как к инструменту, могут быстро его освоить и худо-бедно читать/писать.
От настроек проекта на самом деле зависит. Но {$R+} включает проверку в рантайме принудительно.
для динамических массивов емнип всё равно это не помогает.
В любом случае, защита в примитивном одноразовом коде без подложенной в нужных местах соломки, скорее всего, приведёт к вылету из программы.
Наши математики очень любили объявлять внутри функции локальный статический массив для одной итерации, а потом его оттуда вернуть. Такие расчёты на сетках работали на явных методах и с треском сходили взрывались на неявных — это буквально с ума сводит людей, не понимающих модель памяти.
UFO just landed and posted this here
UFO just landed and posted this here
по потреблению ресурсов на тривиальных задачах
UFO just landed and posted this here
UFO just landed and posted this here
1. На STM помощнее заведётся (micropython), для attiny и выбора-то языка особо не стоит. Но с переносимостью между обычными x86 и arm всё нормально, и явно проще всяких C.
2. Понятно, чего именно простота — быстро набросать программку для конкретных расчётов, добавить туда построение графиков, или сделать скрипт например, простой веб-сайт… И в это (по отдельности) можно реально за день въехать почти с нуля. Поддержка, особенно больших проектов, конечно страдает (увы).
3. После C, фортрана, перла, шелла,… В общем, по сравнению с другими языками, которые по факту на питон частенько и заменяются.
2. Понятно, чего именно простота — быстро набросать программку для конкретных расчётов, добавить туда построение графиков, или сделать скрипт например, простой веб-сайт… И в это (по отдельности) можно реально за день въехать почти с нуля. Поддержка, особенно больших проектов, конечно страдает (увы).
3. После C, фортрана, перла, шелла,… В общем, по сравнению с другими языками, которые по факту на питон частенько и заменяются.
что Вы понимаете под словом «универсальный»?
Удачи в написании на Питоне низкоуровневого драйвера устройства. Или ОС реального времени.
Python, Delphi и C++ глазами учёного