точного ничего в природе нет. вы должны сделать оценку вашей функции. и сравнить с точностью, с которой представляются числа в компьютере. в процессе вычислений вы должны контролировать эти величины и при расхождении немедленно прерывать цикл.
Есть доказанные гарантии метода. Есть определённая величина шага по сетке и по времени, которая для данного класса функций будет гарантировать сходимость к правильному решению. И есть формулы для их расчёта.
иногда требуется переписать цикл, благо в с++ их несколько разновидностей.
Которые взаимозаменяемы. Можно ещё вспомнить в каком-то из языков отдельные операнды iftrue/iffalse — такие вещи нужны если вдруг употребление именно этого слова сделает код понятнее. Но потоку как-то пофиг. Вы можете реализовать один и тот же цикл как while..do, и как repeat..until. И если потрудиться учесть наличие первого прогона и форму условия, они будут эквивалентны.
ваш пассаж из статьи, что программа будет запущена максимум только один раз меня рассмешил.
С постоянным выводом данных это не проблема. Нет никакой разницы в методах. Вопрос в дроблении кода на части. Я раздробил так, чтобы получить график. Если бы я решил по другому, и сначала бы проверил что одна итерация отрабатывает — то я бы увидел что она работает с моими начальными условиями. Это и так понятно. С другой стороны, когда я выбрал сразу много считать, я всё равно получил информацию о том что отдельные итерации с начальными значениями на входе работают — когда в консоль начали валиться данные.
ваша оценка в 32 бита взята с потолка (см. пункт а). почти всегда, вернее никогда в научных расчетах не используются простые типы данных. нам приходилось писать свои библиотеки для представления чисел и обеспечения точности вычислений.
6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима. Если говорить об области применения кода, виновника торжества, то это область где даже качественное поведение функции и значения в пределах 10% точности были прорывом. Потому что экспериментальных приборов для измерения таких вещей даже косвенным образом — не существовало. Но что касается точности модели — то вы, должно быть, не знаете, как оценивать косвенную погрешность таких вычислений.
Писать — хоть на чём. А методички отпечатаны только по одному)
Рассказ о вычислениях у нас обычно был не связан с кодом, а с мат теорией самого метода, который должен был быть реализован в лабе.
Я рад что С развивается, но вот направление этого развития всё ещё подчиняется идеологии минимализма (ака сделай сам) и того самого фирменного си-стиля со звёздочками (я плотно не слежу, но читал обзоры на стандарты, и по ним сложилось именно такое впечатление).
Лично я уже не так боюсь С как раньше, мне в этом помог видеокурс с растолкованием разименования, системы памяти и того, зачем вообще создали С, но я понимаю что для приблизительного понимания кода С, или С++ нужно: потратить хотя бы два месяца на разбор базы, месяц покодить, потратить ещё месяц на разбор ошибок в своём коде с книжками в руках, и только к концу 4-5 месяца начинаешь только понимать что вокруг происходит.
На Пайтоне же, порог вхождения примерно такой: умеешь упорядочить свои мысли и написать блоксхему работы желаемого кода — это уже больше необходимого чтобы взять и написать. Это очень удобно для людей, которые тратят кучу времени на другие сферы своей жизни, работая не программистами, а, скажем, учёными, которым необходимо время от времени напсать какую-то программку. Проблемы с Пайтоном у меня возникают реже не потому, что я лучше его знаю, а потому что интуитивно написанный код в нём работает гораздо чаще, т.е. надо знать минимум специфики языка, чтобы эффективно им пользоваться.
Сам я нигде не работал 3 месяца, пока изучал C# — а потом выкраивал время чтобы освоить новый прикладной пакет для вычислений, пока со всех сторон наседали проекты, которые обязан делать. Но я понимаю что в таком режиме работать может далеко не каждый, и, вспоминая старые добрые времена, понимаю что освоение Пайтона заняло у меня 2 дня. Один день — прочитать методу после пар. 2 день — написать «привет, мир», мешалку массивов, казуальную игру и смоделировать систему с динамическим хаосом. Язык реально понятен как пень. С си пришлось осваивать какие-то новые концепции памяти и так далее…
Вот правду говорят, что на изучение нового языка после первого тратишь меньше времени. Я реально после паскаля все остальные быстрее осваивал. Кроме си. Так что он, хоть уже и не пугает, но вызывает больше неприятных ассоциаций, чем пайтон (кстати, даже на джулию я больше времени в итоге потратил, чем на него).
А ещё так было в Гарварде в 2000-е. И в университете Северной Каролины в 2010-х. И в Карловом университете в 2015-м. «in-house closed source software» — это повсеместная практика, никак нее связанная с СССР. Я её встречаю в статьях гораздо чаще, чем ссылки на гитхаб. Причины тут две 1) хороший код — можно запатентовать и получать доход 2) плохой код — стыдно показать, да и всё-равно никто не разберётся. Часто сталкивался с этим, когда и самому нужен такой код, а в итоге приходится писать всё самому. Часто бывает так что опубликованы версии для матлаба и с++, матлаб версия работает, а си-версию надо самому доделывать, чтобы она хотя бы начала компилироваться. Вот это я очень не люблю, почти месяц из-за таких умельцев потратил на кодинг. Тоже хорошая кулстори, про очень долгий дебаг. Вместо интерфейса у них было бесчисленное множество аргументов командной строки, а в документации кое-что перепутано.
Так что роста значения и качества программ в науке я пока не замечаю.
Что касается историй о потеряных эн годах, то в научном мире есть исследования других групп — которые в любой момент могут перепроверить результат (и это делается для многих важных открытий), не думаю что такой обман может долго жить, даже если рассказан только по секрету. Гораздо большую проблему, на мой взгляд, представляют те споры с регулярным выпуском статей на тему того что проекция объекта круг — нет квадрат — нет круг, когда объект, вообще-то, цилиндр. И вместо объединения подходов создаётся штамповка статей где они противопоставляются.
Нет, ну есть факторизация. Которая развязывает системы. И они могут относится к разной природе. Их можно назвать «система уравнений, описывающая систему», но это не несёт никакой дополнительной информации. Лучше говорить отдельно о системе для параметра К, и об общей системе, которая описывает, к примеру, фазовый портрет всего происходящего, ну а К в ней фигурирует уже как зависимый параметр
.
Тут были и С/С++, и Python, и Matlab, и Julia, и R
Очень странно слышать. Либо научная группа которая занимается в основном численными расчётами. В моём окружении такой человек один на 6-8 (среди тех кто занимается наукой, без учёта тех кто фрилансит, а это половина). Экспериментальщики чаще доверяют установкам, теоретики — бумаге. Т.е. должна быть группа которая вся целиком занималась бы симуляциями — тогда в ней можно было бы вести такие разговоры. Но по-моему больше всех всё-таки смешанных групп, где один-два занимаются моделированием. И на втором месте чистые группы из экспериментаоров. И это статистика не по стране, а скорее общемировая — у англичан и поляков экспериментаторов тоже везде больше всех.
расчёты действительно бывают очень «тяжёлыми»
Ну так в этом и искусство. Часть решить аналитически, часть не учитывать, и так далее.
Поскольку значительное количество рабочего времени ты пишешь код
Вот это подтверждает мою версию, что у вас очень спецефичная группа. Обычно значительную часть времени занимают обсуждения, анализ, чтение свеженьких статей, и так далее. Если говорить о часте работы именно в исследовании — то анализ обычно дольше написания кода. Вернее как-то так происходит, что обсуждается новый график 2 часа, в итоге идём на другой этаж к эксприментатору который что-то такое делал, спрашиваем — а сколько там вообще атомов в кластере такого типа бывает, ещё 4 часа обсуждения ситуации и какой именно кластер, и какие условия зарождения, в итоге получаем одну единственную цифру, возвращаемся, вбиваем эту одну цифру и ещё пару строк кода. Оставляем на ночь считать. Утром красота, вискеры заколосились. Только визуализацию на фото наложи. Т.е. в итоге-то написание кода довольно крошечную часть времени занимает. Даже если с нуля писать, как ни странно.
и приходит понимание того, что ты просто не хочешь писать код, который будет заставлять людей страдать;
Я абсолютно согласен. К сожалению, иногда и в офисах IT компаний пишут такой код.
Но иногда код — это действительно одноразовый инструмент.
«Нет ничего более постоянного, чем временное». Вот вы сколько раз запускали каждую программу как минимум для того, чтобы отладить? А когда вы докрутите какой-нибудь новый параметр в вашей системе, вы заново весь код для получения новых картинок преписывать будете? Или «макаронный код» наплодите? Или вы больше никогда не будете решать уравнения численно и возвращаться к этому коду, чтобы «подглядеть» свой собственный опыт?
Один из лучших умов, что я знаю, пишет макаронный код в виде страниц текста «по ширине», с готу и прочим. Он при мне мгновенно сориентировался в своём диком коде и дописал фичу спустя десять лет после написания. Наша с ним общая черта — нам всем легко разбираться в своём коде, даже если он супер-нечитабелен.
А вы-то тут причём?
Это не при чём) Это к разным относилось частям.
лаба по численным методам где-то за 3-ий курс, я подозреваю, что подключаемых библиотек с простым интерфейсом, которые могут порешать это за вас, должно быть достаточно
Только если коэффициенты не пересчитываются на ходу методом стрельбы. Это трёхвложенный цикл решающий две зависимые системы уравнений. Слишком особый случай. Именно для таких и нужно умение писать программы, иначе всё бы на листах маткада делалось бы…
А именно то, что код редко всерьёз покрывается тестами
Тесты должны знать что должно получится. Симуляции пишутся, когда не вполне уверен что должно получится — но есть не менее двух ожидаемых результатов, которые подтвердят теорию/корректность модели, либо нет.
1)-2) после включения программы я не могу работать в системе. Виновата этом программа, но систему всё равно придётся перезагружать, ничего не отвечает, процесс съел всё. Вы знаете что это не падение системы. Для меня — разницы никакой. Машина не функционирует.
3) Не валит. Я использю одну и ту же библиотеку из пайтона и из С++.
4) Если вы продвинутый плюсовик — ок. Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи? Есть for, else, array — вещи, которіе узнаются во многих языках и понятны. try{} catch(){}, std::bad_alloc, std::out_of_range — это есть не везде. Более того, когда вы открываете чужой код, и видите все расчёты без этих вот штук — вы не знаете что их нужно дописать. Это нифига не очевидно. (на всякий случай напоминаю, что нерабочие коды на си и делфи написал не я — я только пытался помочь разобраться людям написавшим их, почему они не заработалали (а люди, которые их писали — знают совершенно точно, что языки программирования — это ада, фортран, паскаль и сиплюсплюс, они во многом ещё электронную почту и интернет не освоили, потому что впервые столкнулись с необходимостью моделирования. Обратились они ко мне, поскольку в отличие от них я изучал один язык в школе и в университете, и это в любом случае больший опыт чем у них. К си ни их, ни нас жизнь тогда не подготовила.))
5) иногда файл повреждён, и хотя имеет правильный формат, в нём неправильное число каналов. Я сталкивался с такими картинками. Если подтягиваете из интернета картинку с расширением png — ожидаете 4 канала. Но это не всегда так, в чём я и убедился, после написания той программы.
6) Надо было использовать формат той библиотеки, которая была нужна.
Если очередной отличник не переписывает алгоритм — программа работает в разы медленнее чем нужно, поскольку отличник оптимизирует код под конкретную задачу, а создатель библиотеки его задачи не знал.
7) Я расчитывал рост нанокристалов в 3д среде на миллиард частиц на пайтоне, было дело. И собирал данные шумовой загрязнённости в городе) Как ни странно оба названных вами примера очень близки к тем вещам которые делал я. Только одно я делал прямо пайтоном, а другое — в специализированном матпакете (без программируемых частей). У меня всё было достаточно быстро на мощном компе. Плюс, иногда программа работала где-то на фоне в течение дней, это да. Но прочитать все нужные статьи по вопросу и потом анализировать данные — это всё равно дольше. Так что время полного исследования не особо экономится.
C# точно так же язык со сборщиком мусора. Это не C++. Хадуп нужен для баз данных. Редко необходимая вещь в симуляциях. Разве что большой банк данных вытащить… Но что дальше с ними делать? Мэппить? Это разве только для статистики может пригодится, не для численых расчётов, как мне кажется.
Программирование надо знать — но совсем не обязательно знать системное и низкоуровневое программирование.
Почти любой код с глобальными переменными. Если написать код в Пайтоне весь в корне, не в функциях, и то же самое сделать в Джулии — то Джулия подтормаживает серьёзно. Наверное это компилируется код на каждом запуске, вместо того чтобы один раз при первом, как когда оформлено в виде функций. Короче, не знаю почему, но дико тупит интерпретатор, если не запаковать всё в функции.
C и С++ изучают только программисты. Естественнонаучники (за очень редким исключением) учат программирование на Делфи, а потом всякие спецпакеты. Максимум пролог будет. Там не учат С98. Там не учат что памятью в принципе можно управлять. Тем более — что нужно. Учат так: вы придумываете правильный алгоритм, компьютер его выполняет. Учат как переписать алгоритм из головы на паскаль. В дальнейшем учат параллельно матпакеты, пакеты симуляций, численные методы (теорию) и учат моделировать на практике — могут посоветовать использовать пайтон, или делфи, но ничто не мешает использовать любой язык: код никогда не смотрят, только результат в виде графиков и фазовых портретов.
Когда я год назад начал программировать на си я внезапно узнал что а) Память вообще где-то вручную выделяют б) что этим занимается программа (раньше я думал что возня с памятью — это исключительно работа ОС) в) что это не только можно, но и нужно делать в некоторых языках г) что си — один из таких языов и д) что означают бесконечные звёздочки в коде, и что такое инкремент ссылки в принципе.
До того как мне это понадобилось с си, я спокойно программировал и моделировал 14 лет на разных языках, ни разу не сталкиваясь с необходимостью высвобождать память, работать с указателями и всё в таком роде.
Использовать умные указатели и исключения — это уже следующий уровень. На тот момент, который я описал в статье, я вообще не знал о существовании прямой работы с памятью. А программировал при этом, соответственно, 9 лет (паскаль и скриптовые языки).
Конечно была масса проверок
а) после расчёта данные дали правильный спектр значений состояний при комнатной температуре
б) после расчёта конечную точку подали на вход и расчитали в обратную сторону обратный процесс, он вывел систему в исходное состояние на нужном этапе
в) момент фазового перехода (экстремум графика) сошёлся с внешней к модели теорией
т.е. проверка по характеристикам спектра, +точка верификации в экстремуме, и по сходимости к исходному состоянию. Если говорить о теории в целом — то с тех пор прошло 6 лет, и за это время численное моделирование успели повторить в независимой команде с идентичным основным графиком, а также сама модель расширилась и опубликованы новые работы подтверждающие наличие ещё одного фазового перехода (который я открыл в тот раз, анализируя данные из Пайтона, то есть это также подтверждает их правильность)
Можно было, конечно, заняться точным расчётом сходимости, когда и функция, и её производная уже известны, но это не обязательно, так как расходимость обычно сразу либо видна на глаз из-за переполнения, либо (реже) неустойчиво уводит в сторону медленно, но верно, а в таком случае невозможно вернуться из тех точек к исходному состоянию, на то она и расходимость.
Положим вы ожидали, что на вход придёт изображение четырёхканальное, а оно пришло с тремя (без прозрачки). Аллокатор встроен куда-то глубоко в готовую функцию из библиотеки, которую вы используете. А вот работать с данными нужно вам конкретно здесь, в этой программе. Тогда вы начинаете перебирать пиксель за пикселем, и производить некие операции, скажем свёртки. При чём библиотека эта устроена так, что перевыделяет память на набор строк изображения, скажем на 3, либо на 5. В какой-то момент вы в коде продолжаете умножать до упора. А данных картинки под вашим свёрточным ядром уже нет. Какое-то время откомпиленный код перемножает случайные числа в неизвестных областях памяти, затем доходит до защищённой области и программа вываливается.
Да, безусловно, есть ошибка программиста, что не предусмотрен ввод изображений с разным количеством каналов. Но в любом языке где массив данных — это какая-никакая абстракция имитирующая реальный массив чисел, такого бы не могло случится — потому что реальные наборы чисел не включают ничего, что находится за их пределами, и ссылки на элементы должны вести себя подобно отдельному новосозданному типу — переполнятся, и всегда оставаться в нужных пределах. Даже если сам массив динамический — это никак не мешает делать поправки, пока выделяешь ему память на рантайме. Данные в таком языке всё равно были бы неправильные, что сказало бы программисту о проблеме. Но вылетать такая программа бы не стала. И никакой опасности для системы и других потоков вычислений представлять в принципе не способна. Почему-то для меня эррейтый элемент нуля не является чем-то осмысленным, а у С это будет точно такое же разыменование. Задумывались ли вы, как так то? Абстрактное понятие о масивах у человека есть, а реализации в C по сути нет. Не говоря уже о строках — это вообще для человека ясная вещь. Для С — ткой же дырявый массив слегка дырявых чаров. А если язык не стремится создавать более высокоуровневые абстракции, и с презрением отзывается о них как о синтаксическом сахаре, тогда чем он лучше кода ассемблера? (кроссплатформенность не в счёт, можно с таким же успехом написать транслятор одного ассемблера в другой, любой нестандартный (подобно тому как делают компилятор С отдельно для каждой платформы)).
К ошибкам в доступе к памяти приводит (чаще всего) неизолированность динамических массивов, которая является прямым следствием того, что массивы С — на самом деле не настоящие массивы данных — цельные объекты, а всего-лишь ссылки на 0-элемент, с прикрученным парсингом обращений в стиле массив[переменная-число]=>*(массив+переменная-число).
Просто информация для человека работавшего в науке:
а) метод стрельбы, к примеру, полагается на точное знание асимптотики функции, и должен вести счёт до попадания в небольшую окрестность этого конечного результата. Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
б) необходимая точность для гарантии сходимости выбранного численного метода расчитывается из теории, и прежде чем выделять память программно правильно, нужно заранее расчитать некоторые величины. В физике есть 3 способа оценить необходимые для такого расчёта величины: 1) теория (аналитического решения нет); 2) численное моделирование (рекурсия, см. пункт б)); и 3) эксперимент (скорость охлаждения в исследуемом процессе~10^6К/с, данных столько же, сколько у слепого котёнка). Так что, справедливо взвесив возможности, можно сказать (и даже написать отчёт) что задача неразрешима и невычислима. А можно прикинуть любую случайную длину, скажем 32 бита для начала, а уже затем увидеть где есть расходимости и поднять точность для таких «узких мест».
А то люди так много открытий потеряют… Которые ТЗ не соответствуют.
Вот видите, это ещё и какой-то не типичный баг. Выходит, правильно я тогда решил не разбираться, а переписать на Python.
Но если зависание системы — это не совсем типичный баг для плюсов на современных ОС, то всякие проблемы с доступом к памяти, либо ub — это вещь встречающаяся повсеместно. (я говорю сейчас не только об учёных, но вообще о программистах — сейчас ub можно внезапно обнаружить и в популярных библиотеках)
Спасибо. Сам я уже с тех пор написал много всякого на С# и C++ (даже до С один раз дело доходило...), но моим коллегам пригодится. Проблема в том что кроме вашего совета тут в комментариях их уже очень много. И куда смотреть неясно — D, FSharp, scheme, common lisp, Fortran, Julia, R, Guile и Lush.
Что тут выбрать из букета? Осваивать все эти вещи и изучать что где применяется? Слишком много их всё-таки. Люди выбирают в итоге то, что на слуху. Вот я могу сказать как обстоят дела в науке. Люди в возрасте до 32 лет чаще всего используют пайтон. А наслышаны про
1) Пайтон 2) Фортран 3) Джулия, а также про 4) Паскаль 5) Си, но последние 2 не используют.
Среди старшего поколения чаще пишут на Паскале, и только в последнее время начали перенимать из-за бугра Фортран. Они слышали про Пайтон и Си ещё, но предпочитают использовать то, по чему на полке лежит учебник советских времён, т.е. дед Паскаль.
Многое просто решается в Математика/Матлаб/аналогичный пакет. Для программ используют один инструмент, обычно тот, которому первому научили. Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел. Даже те кто работает/работал программистом, хоть и знают некоторые альтернативы, всё равно придерживаются максимально простых решений, когда занимаются наукой.
Я всё-таки выразился не совсем корректно. Имелась ввиду необходимость перезагрузки. Про запись логов мне уже сказали, спасибо, теперь я буду это знать.
Интересная вещь — всё, чего когда либо на моей памяти касались (из области программирования) на защитах физиков, это «в чём сделана такая визуализация?» — и то, только в случае если визуализация красивая, и кто-то из комиссии тоже такой график поверхности себе захотел.
И здесь речь скорее не о дебаге, а о полной разработке, т.к. в последнем случае дебага нет. Вы сначала описали, условно говоря, бизнес-логику вашей программы, сами выражения и в каком порядке и сколько раз их расчитывать — это занимает примерно одно и то же время на всех языках. После этого ваш код на Python — уже работает, на Delphi — надо немного доработать, на С++ — надо некоторое значительное время бороться с вылазящими из под половицы драконами.
Насколько я понял, у вас есть программа и из-за её работы вы не можете управлять компьютером? Тут проблема с самой программой, которая некоректно потребляет ресурсы системы
Ну именно поэтому программу нужно было исправлять — если бы она хоть раз заработала, она сразу после этого стала бы не нужной, т.к. уже спродуцировала нужные данные.
Знаете, интересно что все программы были одинаковыми. Функции объявлены по разному, но делают с входными данными тоже самое, и выводят те же величины. Основная функция (процедура в делфи) делает одно и то же.
Когда человек пишет программу — она может с первого раза не заработать как он ожидает. Тогда он ищет где ошибки, и как правило процесс разработки начинается с неисправной программы (неверной). Бывают блокеры, бывают мелкие баги. Это не значит что программа плоха, это значит, что её дорабатывают. Поэтому мне не нравится называть программу, которая не выполняет ожидаемое, неверной.
Программа на С++ могла бы тоже вывести график, но вместо этого всё ломала. Она бы не вывела значений после критической точки, а делфи начал выводить неправильные — это само по себе полезная информация, да ещё и время на перезагрузку не тратится. Ну а Пайтон заработал не по вине разработчика — я не написал там ничего, чего не было в кодах на си и паскале. Я написал ровно то же — не импортировал никаких протекторов, не ковырялся в параметрах запуска, не лез в консоли, не писал проверок и тестов.
пункты 1-2, как мне кажется, не относятся ко всем трём языкам. А 3 — это не Задача, это этап, который должен был быть сделан, пусть это и две строчки кода.
Как и вы бы у меня.
Есть доказанные гарантии метода. Есть определённая величина шага по сетке и по времени, которая для данного класса функций будет гарантировать сходимость к правильному решению. И есть формулы для их расчёта.
Которые взаимозаменяемы. Можно ещё вспомнить в каком-то из языков отдельные операнды iftrue/iffalse — такие вещи нужны если вдруг употребление именно этого слова сделает код понятнее. Но потоку как-то пофиг. Вы можете реализовать один и тот же цикл как while..do, и как repeat..until. И если потрудиться учесть наличие первого прогона и форму условия, они будут эквивалентны.
С постоянным выводом данных это не проблема. Нет никакой разницы в методах. Вопрос в дроблении кода на части. Я раздробил так, чтобы получить график. Если бы я решил по другому, и сначала бы проверил что одна итерация отрабатывает — то я бы увидел что она работает с моими начальными условиями. Это и так понятно. С другой стороны, когда я выбрал сразу много считать, я всё равно получил информацию о том что отдельные итерации с начальными значениями на входе работают — когда в консоль начали валиться данные.
6 знаков после запятой. Это самая большая точность, которую я когда-либо видел у знакомых, с которыми могу поговорить и лично убедиться, что такая точность необходима. Если говорить об области применения кода, виновника торжества, то это область где даже качественное поведение функции и значения в пределах 10% точности были прорывом. Потому что экспериментальных приборов для измерения таких вещей даже косвенным образом — не существовало. Но что касается точности модели — то вы, должно быть, не знаете, как оценивать косвенную погрешность таких вычислений.
Рассказ о вычислениях у нас обычно был не связан с кодом, а с мат теорией самого метода, который должен был быть реализован в лабе.
Лично я уже не так боюсь С как раньше, мне в этом помог видеокурс с растолкованием разименования, системы памяти и того, зачем вообще создали С, но я понимаю что для приблизительного понимания кода С, или С++ нужно: потратить хотя бы два месяца на разбор базы, месяц покодить, потратить ещё месяц на разбор ошибок в своём коде с книжками в руках, и только к концу 4-5 месяца начинаешь только понимать что вокруг происходит.
На Пайтоне же, порог вхождения примерно такой: умеешь упорядочить свои мысли и написать блоксхему работы желаемого кода — это уже больше необходимого чтобы взять и написать. Это очень удобно для людей, которые тратят кучу времени на другие сферы своей жизни, работая не программистами, а, скажем, учёными, которым необходимо время от времени напсать какую-то программку. Проблемы с Пайтоном у меня возникают реже не потому, что я лучше его знаю, а потому что интуитивно написанный код в нём работает гораздо чаще, т.е. надо знать минимум специфики языка, чтобы эффективно им пользоваться.
Сам я нигде не работал 3 месяца, пока изучал C# — а потом выкраивал время чтобы освоить новый прикладной пакет для вычислений, пока со всех сторон наседали проекты, которые обязан делать. Но я понимаю что в таком режиме работать может далеко не каждый, и, вспоминая старые добрые времена, понимаю что освоение Пайтона заняло у меня 2 дня. Один день — прочитать методу после пар. 2 день — написать «привет, мир», мешалку массивов, казуальную игру и смоделировать систему с динамическим хаосом. Язык реально понятен как пень. С си пришлось осваивать какие-то новые концепции памяти и так далее…
Вот правду говорят, что на изучение нового языка после первого тратишь меньше времени. Я реально после паскаля все остальные быстрее осваивал. Кроме си. Так что он, хоть уже и не пугает, но вызывает больше неприятных ассоциаций, чем пайтон (кстати, даже на джулию я больше времени в итоге потратил, чем на него).
А ещё так было в Гарварде в 2000-е. И в университете Северной Каролины в 2010-х. И в Карловом университете в 2015-м. «in-house closed source software» — это повсеместная практика, никак нее связанная с СССР. Я её встречаю в статьях гораздо чаще, чем ссылки на гитхаб. Причины тут две 1) хороший код — можно запатентовать и получать доход 2) плохой код — стыдно показать, да и всё-равно никто не разберётся. Часто сталкивался с этим, когда и самому нужен такой код, а в итоге приходится писать всё самому. Часто бывает так что опубликованы версии для матлаба и с++, матлаб версия работает, а си-версию надо самому доделывать, чтобы она хотя бы начала компилироваться. Вот это я очень не люблю, почти месяц из-за таких умельцев потратил на кодинг. Тоже хорошая кулстори, про очень долгий дебаг. Вместо интерфейса у них было бесчисленное множество аргументов командной строки, а в документации кое-что перепутано.
Так что роста значения и качества программ в науке я пока не замечаю.
Что касается историй о потеряных эн годах, то в научном мире есть исследования других групп — которые в любой момент могут перепроверить результат (и это делается для многих важных открытий), не думаю что такой обман может долго жить, даже если рассказан только по секрету. Гораздо большую проблему, на мой взгляд, представляют те споры с регулярным выпуском статей на тему того что проекция объекта круг — нет квадрат — нет круг, когда объект, вообще-то, цилиндр. И вместо объединения подходов создаётся штамповка статей где они противопоставляются.
.
Очень странно слышать. Либо научная группа которая занимается в основном численными расчётами. В моём окружении такой человек один на 6-8 (среди тех кто занимается наукой, без учёта тех кто фрилансит, а это половина). Экспериментальщики чаще доверяют установкам, теоретики — бумаге. Т.е. должна быть группа которая вся целиком занималась бы симуляциями — тогда в ней можно было бы вести такие разговоры. Но по-моему больше всех всё-таки смешанных групп, где один-два занимаются моделированием. И на втором месте чистые группы из экспериментаоров. И это статистика не по стране, а скорее общемировая — у англичан и поляков экспериментаторов тоже везде больше всех.
Ну так в этом и искусство. Часть решить аналитически, часть не учитывать, и так далее.
Вот это подтверждает мою версию, что у вас очень спецефичная группа. Обычно значительную часть времени занимают обсуждения, анализ, чтение свеженьких статей, и так далее. Если говорить о часте работы именно в исследовании — то анализ обычно дольше написания кода. Вернее как-то так происходит, что обсуждается новый график 2 часа, в итоге идём на другой этаж к эксприментатору который что-то такое делал, спрашиваем — а сколько там вообще атомов в кластере такого типа бывает, ещё 4 часа обсуждения ситуации и какой именно кластер, и какие условия зарождения, в итоге получаем одну единственную цифру, возвращаемся, вбиваем эту одну цифру и ещё пару строк кода. Оставляем на ночь считать. Утром красота, вискеры заколосились. Только визуализацию на фото наложи. Т.е. в итоге-то написание кода довольно крошечную часть времени занимает. Даже если с нуля писать, как ни странно.
Я абсолютно согласен. К сожалению, иногда и в офисах IT компаний пишут такой код.
Но иногда код — это действительно одноразовый инструмент.
Один из лучших умов, что я знаю, пишет макаронный код в виде страниц текста «по ширине», с готу и прочим. Он при мне мгновенно сориентировался в своём диком коде и дописал фичу спустя десять лет после написания. Наша с ним общая черта — нам всем легко разбираться в своём коде, даже если он супер-нечитабелен.
Это не при чём) Это к разным относилось частям.
Только если коэффициенты не пересчитываются на ходу методом стрельбы. Это трёхвложенный цикл решающий две зависимые системы уравнений. Слишком особый случай. Именно для таких и нужно умение писать программы, иначе всё бы на листах маткада делалось бы…
Тесты должны знать что должно получится. Симуляции пишутся, когда не вполне уверен что должно получится — но есть не менее двух ожидаемых результатов, которые подтвердят теорию/корректность модели, либо нет.
3) Не валит. Я использю одну и ту же библиотеку из пайтона и из С++.
4) Если вы продвинутый плюсовик — ок. Объясните, откуда человек впервые открывший код на новом языке будет знать такие вещи? Есть for, else, array — вещи, которіе узнаются во многих языках и понятны. try{} catch(){}, std::bad_alloc, std::out_of_range — это есть не везде. Более того, когда вы открываете чужой код, и видите все расчёты без этих вот штук — вы не знаете что их нужно дописать. Это нифига не очевидно. (на всякий случай напоминаю, что нерабочие коды на си и делфи написал не я — я только пытался помочь разобраться людям написавшим их, почему они не заработалали (а люди, которые их писали — знают совершенно точно, что языки программирования — это ада, фортран, паскаль и сиплюсплюс, они во многом ещё электронную почту и интернет не освоили, потому что впервые столкнулись с необходимостью моделирования. Обратились они ко мне, поскольку в отличие от них я изучал один язык в школе и в университете, и это в любом случае больший опыт чем у них. К си ни их, ни нас жизнь тогда не подготовила.))
5) иногда файл повреждён, и хотя имеет правильный формат, в нём неправильное число каналов. Я сталкивался с такими картинками. Если подтягиваете из интернета картинку с расширением png — ожидаете 4 канала. Но это не всегда так, в чём я и убедился, после написания той программы.
6) Надо было использовать формат той библиотеки, которая была нужна.
Если очередной отличник не переписывает алгоритм — программа работает в разы медленнее чем нужно, поскольку отличник оптимизирует код под конкретную задачу, а создатель библиотеки его задачи не знал.
7) Я расчитывал рост нанокристалов в 3д среде на миллиард частиц на пайтоне, было дело. И собирал данные шумовой загрязнённости в городе) Как ни странно оба названных вами примера очень близки к тем вещам которые делал я. Только одно я делал прямо пайтоном, а другое — в специализированном матпакете (без программируемых частей). У меня всё было достаточно быстро на мощном компе. Плюс, иногда программа работала где-то на фоне в течение дней, это да. Но прочитать все нужные статьи по вопросу и потом анализировать данные — это всё равно дольше. Так что время полного исследования не особо экономится.
Программирование надо знать — но совсем не обязательно знать системное и низкоуровневое программирование.
Когда я год назад начал программировать на си я внезапно узнал что а) Память вообще где-то вручную выделяют б) что этим занимается программа (раньше я думал что возня с памятью — это исключительно работа ОС) в) что это не только можно, но и нужно делать в некоторых языках г) что си — один из таких языов и д) что означают бесконечные звёздочки в коде, и что такое инкремент ссылки в принципе.
До того как мне это понадобилось с си, я спокойно программировал и моделировал 14 лет на разных языках, ни разу не сталкиваясь с необходимостью высвобождать память, работать с указателями и всё в таком роде.
Использовать умные указатели и исключения — это уже следующий уровень. На тот момент, который я описал в статье, я вообще не знал о существовании прямой работы с памятью. А программировал при этом, соответственно, 9 лет (паскаль и скриптовые языки).
а) после расчёта данные дали правильный спектр значений состояний при комнатной температуре
б) после расчёта конечную точку подали на вход и расчитали в обратную сторону обратный процесс, он вывел систему в исходное состояние на нужном этапе
в) момент фазового перехода (экстремум графика) сошёлся с внешней к модели теорией
т.е. проверка по характеристикам спектра, +точка верификации в экстремуме, и по сходимости к исходному состоянию. Если говорить о теории в целом — то с тех пор прошло 6 лет, и за это время численное моделирование успели повторить в независимой команде с идентичным основным графиком, а также сама модель расширилась и опубликованы новые работы подтверждающие наличие ещё одного фазового перехода (который я открыл в тот раз, анализируя данные из Пайтона, то есть это также подтверждает их правильность)
Можно было, конечно, заняться точным расчётом сходимости, когда и функция, и её производная уже известны, но это не обязательно, так как расходимость обычно сразу либо видна на глаз из-за переполнения, либо (реже) неустойчиво уводит в сторону медленно, но верно, а в таком случае невозможно вернуться из тех точек к исходному состоянию, на то она и расходимость.
Да, безусловно, есть ошибка программиста, что не предусмотрен ввод изображений с разным количеством каналов. Но в любом языке где массив данных — это какая-никакая абстракция имитирующая реальный массив чисел, такого бы не могло случится — потому что реальные наборы чисел не включают ничего, что находится за их пределами, и ссылки на элементы должны вести себя подобно отдельному новосозданному типу — переполнятся, и всегда оставаться в нужных пределах. Даже если сам массив динамический — это никак не мешает делать поправки, пока выделяешь ему память на рантайме. Данные в таком языке всё равно были бы неправильные, что сказало бы программисту о проблеме. Но вылетать такая программа бы не стала. И никакой опасности для системы и других потоков вычислений представлять в принципе не способна. Почему-то для меня эррейтый элемент нуля не является чем-то осмысленным, а у С это будет точно такое же разыменование. Задумывались ли вы, как так то? Абстрактное понятие о масивах у человека есть, а реализации в C по сути нет. Не говоря уже о строках — это вообще для человека ясная вещь. Для С — ткой же дырявый массив слегка дырявых чаров. А если язык не стремится создавать более высокоуровневые абстракции, и с презрением отзывается о них как о синтаксическом сахаре, тогда чем он лучше кода ассемблера? (кроссплатформенность не в счёт, можно с таким же успехом написать транслятор одного ассемблера в другой, любой нестандартный (подобно тому как делают компилятор С отдельно для каждой платформы)).
К ошибкам в доступе к памяти приводит (чаще всего) неизолированность динамических массивов, которая является прямым следствием того, что массивы С — на самом деле не настоящие массивы данных — цельные объекты, а всего-лишь ссылки на 0-элемент, с прикрученным парсингом обращений в стиле массив[переменная-число]=>*(массив+переменная-число).
а) метод стрельбы, к примеру, полагается на точное знание асимптотики функции, и должен вести счёт до попадания в небольшую окрестность этого конечного результата. Если на условие его цикла подать неправильное значение асимптотики, то он не достигнет точки выхода никогда, поэтому в некоторых научных задачах ошибка потери разряда сразу же влечёт за собой ошибку бесконечного цикла
б) необходимая точность для гарантии сходимости выбранного численного метода расчитывается из теории, и прежде чем выделять память программно правильно, нужно заранее расчитать некоторые величины. В физике есть 3 способа оценить необходимые для такого расчёта величины: 1) теория (аналитического решения нет); 2) численное моделирование (рекурсия, см. пункт б)); и 3) эксперимент (скорость охлаждения в исследуемом процессе~10^6К/с, данных столько же, сколько у слепого котёнка). Так что, справедливо взвесив возможности, можно сказать (и даже написать отчёт) что задача неразрешима и невычислима. А можно прикинуть любую случайную длину, скажем 32 бита для начала, а уже затем увидеть где есть расходимости и поднять точность для таких «узких мест».
А то люди так много открытий потеряют… Которые ТЗ не соответствуют.
Но если зависание системы — это не совсем типичный баг для плюсов на современных ОС, то всякие проблемы с доступом к памяти, либо ub — это вещь встречающаяся повсеместно. (я говорю сейчас не только об учёных, но вообще о программистах — сейчас ub можно внезапно обнаружить и в популярных библиотеках)
Что тут выбрать из букета? Осваивать все эти вещи и изучать что где применяется? Слишком много их всё-таки. Люди выбирают в итоге то, что на слуху. Вот я могу сказать как обстоят дела в науке. Люди в возрасте до 32 лет чаще всего используют пайтон. А наслышаны про
1) Пайтон 2) Фортран 3) Джулия, а также про 4) Паскаль 5) Си, но последние 2 не используют.
Среди старшего поколения чаще пишут на Паскале, и только в последнее время начали перенимать из-за бугра Фортран. Они слышали про Пайтон и Си ещё, но предпочитают использовать то, по чему на полке лежит учебник советских времён, т.е. дед Паскаль.
Многое просто решается в Математика/Матлаб/аналогичный пакет. Для программ используют один инструмент, обычно тот, которому первому научили. Такое чтобы части кода писались на разных языках, чтобы занимались линковкой мега проектов таких — я ещё не видел. Даже те кто работает/работал программистом, хоть и знают некоторые альтернативы, всё равно придерживаются максимально простых решений, когда занимаются наукой.
Ну именно поэтому программу нужно было исправлять — если бы она хоть раз заработала, она сразу после этого стала бы не нужной, т.к. уже спродуцировала нужные данные.
imgs.xkcd.com/comics/the_difference.png
Нет, про типизацию, и какой пайтон крутой. Я где-то в другом комментарии боле подробно расписал.
Когда человек пишет программу — она может с первого раза не заработать как он ожидает. Тогда он ищет где ошибки, и как правило процесс разработки начинается с неисправной программы (неверной). Бывают блокеры, бывают мелкие баги. Это не значит что программа плоха, это значит, что её дорабатывают. Поэтому мне не нравится называть программу, которая не выполняет ожидаемое, неверной.
Программа на С++ могла бы тоже вывести график, но вместо этого всё ломала. Она бы не вывела значений после критической точки, а делфи начал выводить неправильные — это само по себе полезная информация, да ещё и время на перезагрузку не тратится. Ну а Пайтон заработал не по вине разработчика — я не написал там ничего, чего не было в кодах на си и паскале. Я написал ровно то же — не импортировал никаких протекторов, не ковырялся в параметрах запуска, не лез в консоли, не писал проверок и тестов.
пункты 1-2, как мне кажется, не относятся ко всем трём языкам. А 3 — это не Задача, это этап, который должен был быть сделан, пусть это и две строчки кода.