Comments 12
Я ожидал как минимум порта с Фортрана) Но MATLAB тоже хорошо
Ссылку на репо починил) Фортран да, но сейчас много кто переходит именно с MATLAB, особенно молодежь которая не может разобраться с лицензией и для них матлаб это что‑то на «старпёрском» )) Да и питон быстрее, бенчмарк прогонял, смотри репозиторий
В смысле «разобраться с лицензией»?
Какая среда делает написание и отлаживание физического кода на Питоне таким же удобным как в Матлабе? Чтобы по-быстрому импортировать данные, по-быстрому строить графики? Чтобы легко видеть все переменные, заглядывать внутрь структур, ставить брейкопоинты, выбирать варианты продолжения исполнение кода и т.п.? Часто рекомендуемый Spyder похож, но не настолько богат и удобен. PyCharm Pro тоже похож, но теряет преимущество бесплатности.
Я вижу только причину в свободности Python и отсутствие vendor lock. А если за скоростью гнаться и универсальностью, то проще перейти на Matlab -> C, и подключать к любому языку через FFI.
Надо переписать на Rust! Хе-хе
Если есть реальный запрос на это или что-то подобное, то можем обсудить
С одной стороны, я просто пошутил. Но с другой - выглядит так, что каждый новый порт - это пара процентов от усилий, затраченных на порт на Питон. Есть ли в этом смысл, насколько результат будет востребован, я боюсь предполагать - не очень представляю, насколько критичны предоставляемые Растом преимущества теми, кому нужны такие вычисления. Понятно, что сам факт появления свободного варианта на Python - это куда весомее, чем дополнительное ускорение... Кстати, забыл сказать Вам спасибо: приятно, когда люди делают такие вещи!
https://github.com/modelics/Python-Sphere-RCS.git вроде хорошо считает, в том числе для диэлектрической сферы
На самом деле проблема такая же для различного рода симуляторов схем. EPS и прочие, добавки 1/(delta+x^2) где delta нечто бесконечно малое и прочее и прочее. Тут важнее скорее всего обусловленность задачи. Если она имеет дико разнесённые постоянные времени (пространства), от очень крупной сетки до мельчайшей то здесь NaN/ +-inf скорее exception флажки нежели математика. То есть такие вещи обычно обыгрываются некими fp константами которые предотвращают насыщение и выводят осознанное исключение без математических приветов. Тут либо полу-символические методы если уж совсем дело далеко зашло а-ля правило Лопиталя (например в SPICE есть symbolic derivative) либо все места содержащие деление или умножение дополнять на проверку. В FP умножение большого на малое тоже может дать не очень хороший результат. Тем более в процессорах общего назначения нет теневых разрядов. Например в DSP при заявленной разрядности в 32 бит аккумулятор может быть все 40 (32+тень, guard bits), чтобы не потерять крайние младшие разряды при умножении на малые коэффициенты и обеспечить накопление результата. 0.5*0.5=0.25 а не 0.2, и ошибка накапливается довольно большая, на этот счёт имеется даже определение - "численный разогрев" (numerical heating) требующий double precision
Я перенёс на Python библиотеку, которой физики пользуются двадцать лет. Перевод оказался самой лёгкой частью