Comments 19
Спасибо за разбор! А есть ли какой-то более подробный критерий/гайд по выбору алгоритма оптимизации для конкретной задачи? Скажем, в зависимости от крутизны градиентов, локальных минимумов, периодичности и тп?
PS
у вас Гессиан в методе Ньютона не отображается правильно
Есть опыт, что более важным фактором является качество и безглючность реализации.

Лично я многие годы пользуюсь оптимизациями из библиотеки NAG для Fortran. Есть вариант для C, в частности, этим вариантом Maple пользуется. Говорят, они и для Python выпустили пакет, но лично я его не использовал.
Таки да, NAG не очень подходит для юношей с горящим взором, которые, прямо таки сразу, желают внести свою лепту в теорию и/или практику вычислительной математики. Тем да, проприетарность и невозможность совместного допиливания ломом через колено, как бы не очень.

Но для остепенившихся товарищей, которые уже разобрались, что у них в математике может получиться, чего, увы, уже никогда. Или для тех, кому нужно реальные прикладные задачи решать, надёжно и в прогнозируемые сроки. NAG он для таких.
Ну да, я так и понял:) Тут скорее вопрос, что при покупке для института, например, должно быть хорошее обоснование, почему их, а не тот же scipy.optimize. Но тут вы правы, с опытом приходит и понимание, наверное, так что подожду, пусть полежит в закладках.
Как то уж слишком однобоко у Вас получается. Существует множество организаций, для которых покупка коммерческих математических программ экономически просто нецелесообразна. А практические задачки решать тоже надо, хотя бы и учебные.
Добавим сюда основные преимущества python — интерактивность и простой синтаксис, и получим отличный бесплатный швейцарский нож. Он не заменит пилораму, но для подручной работы намного удобней.
Капитализм, конечно, загнивает, и коммунизм, несомненно, с неизбежностью наступит, и OpenSource часть его (на полном серьёзе). Но надо понимать, что SciPy версии 1.0 появился всего пару лет назад. Для сравнения Linux 1.0 появился 25 лет назад и только последнее время Linux смог претендовать на нишу более менее надёжного швейцарского ножа.

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

Нет, ну если учить вычислительным методам, то можно и студентов знакомить с потрохами и процессом разработки той же SciPy/NumPy. Я, конечно, ретроград, и предпочел бы их учить на примере исходных кодов NAG для Fortran, или, на крайний случай, NAG для C. Ибо откуда они ещё узнают, как это должно нормально и надёжно работать?!

«интерактивность и простой синтаксис» — а как бы у MATLAB/Maple/IRAF интерактивность повыше будет. Не?

Учитывая основной недостаток Питона — нелюбовь к многоядерным/многопроцессорным архитектурам, всё таки, увы, Питон не Ява. И SciPy/NumPy, и NAG for Python, осваивают его медленно используя нативный код. По крайней мере, астрономические приложения на Питоне, типа PHOEBE (да, да, с использованием SciPy/NumPy) требуют существенного энтузиазма и всё равно:
PHOEBE 1.0 (legacy) should be used for reliable trustable science results and for cases that do not require the precision or additional physics introduced by PHOEBE 2. PHOEBE 1.0 (legacy) is still significantly faster than PHOEBE 2.

Примечание: PHOEBE 1.0 (legacy) — Питон обёртка FORTRAN кода образца (98..2007), стабильная версия Питон обёртки 2008 года. PHOEBE 2 — продукт почти 15-летних танцев с Питон, потом плюс NymPy, сейчас ещё и SciPy. А доверия всё нет, и нет, ещё и тормозит гад не по детски.

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

Любой институт. Если научная группа не занимается постоянной и сложной оптимизацией, средств scipy обычно хватает с головой, особенно для студентов.
Если нет задачи научиться численным методам, а нужно обработать данные или построить простую модель в ограниченный срок (скажем, полгода-год написания магистерской работы у студентов) — питон в целом идеальный вариант.

«интерактивность и простой синтаксис» — а как бы у MATLAB/Maple/IRAF интерактивность повыше будет. Не?

Jupyter/ipython + любая IDE делают интерактивность питона вполне на уровне Матлаба.

Но в целом насчет скорости разработки вы правы.
… в ограниченный срок (скажем, полгода-год написания магистерской работы у студентов) ...
Вот в этом месте может скрываться засада. Все ж под Богом глюков в программном обеспечении ходим.
… сложной оптимизацией, средств scipy обычно хватает с головой...
Что есть сложная? Чем дольше живу, тем более вычислительно сложные модели (целевые функции) в т.ч. и у студентов/аспирантов. А расчёт вычислительной модели на Pythone/SciPy/NumPy, конечно как повезёт, но бывает и на порядок-два тормознее, чем на C/FORTRAN/MATLAB/Maple.

Плюс, на мой вкус, недоделанный и, главное, не отлаженный код самоих методов оптимизаций и прочих обвязок вплоть до matplotlib. Правда, я ж сам с SciPy имею дело только когда у товарищей и/или товарок проблемы, возможно, умные люди умеют как-то приспосабливаться? Кто знает?
А расчёт вычислительной модели на Pythone/SciPy/NumPy, конечно как повезёт, но бывает и на порядок-два тормознее, чем на C/FORTRAN/MATLAB/Maple.

Сложно сказать, хорошо написанный код на numpy в anaconda (т.е., скажем, с numba) субъективно работает не медленнее Матлаба. C и Fortran сложно, конечно, побить, но зависит от задач, иногда питон и побыстрее будет. Вот можно бенчмарки посмотреть, интереса ради.

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

Насчет кода методов не знаю, тут я совсем не специалист, да и сравнить не с чем. А про обвязки, кажется, все как раз очень неплохо обстоит сейчас: pandas для работы с данными, seaborn для визуализации, интерактивные графики с jupyther в matplotlib. В итоге воркфлоу для обработки данных получается быстрым, удобным и читабельным на выходе: получающийся в итоге ноутбук ipython на мой вкус вообще лучший вариант для научных задач, особенно если нужно делиться с кем-то.
Ну и кстати, питон удобен разнообразием: у нас лабах цифровые контроллеры экспериментов работают на питоне, туда же встроен базовый анализ + документация, с выводом этого через ноутбуки jupyter в лабораторные книги/логи эксперимента. На питоне же написаны стандартные скрипты обработки данных и построения графиков/визуализации. В итоге новому студенту не нужно учить несколько разных языков, особенно специфичных, как фортран, а достаточно знать основы питона, и можно проводить полный цикл эксперимента, от собственно снятия данных до анализа/построения модели и визуализации. А вывод ноутбуков по сути можно прямо вставлять в финальные отчеты.
Где изолента не держит — сварке нечего делать! Или! Если Вам не удается отремонтировать что-нибудь при помощи изоленты, значит у вас мало изоленты!

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

Если говорить за оптимизацию, то «средство оптимизации» вызывает «ваше ядро». Написание ядер (мат.модель) на Питоне:
  • Зашоривает мозги, ибо без векторизации в Питоне всё хреново, поэтому целевые функции, которые не выражаются или трудно выражаются в векторзованном виде, изначально идут лесом;
  • Структура задачи нелинейной оптимизации, даже нелинейного МНК/правдоподобия и т.п., несколько отличаются от линейных, квадратичных и прочих фурье-преобразований. Так что для целевых функций среднего и небольшого размера при сложном рельефе все ваши тесты производительности игнорируются и всё тормозит без всякого стыда и совести;
  • Конечно 99% мат. моделей уходят в утиль в течении пары лет, но 1% выживает. И с мат.моделями из 80-х проблем не имел, а вот, бывает, встретится/притащут что-то на Бейсике/Excel/AXUM. Перепишешь на C/Fortran — ошибок по насажаешь, к гадалке не ходи. Обертку сделаешь — научную достоверность сохранишь, но… И с Питон через 20...30 лет тот же геморрой ожидается;
Давайте еще раз повторим. C/Fortran — это очень хорошо для промышленных приложений.
У python есть свои сформированные ниши, например www.kaggle.com/c/two-sigma-financial-news/kernels — практически все исследования на python.
Мы уже достаточно подробно обсудили сильные и слабые стороны инструмента scipy. Что Вы еще хотите сказать?
PS
Где изолента не держит — сварке нечего делать!
Где русский инженер использует изоленту и водку, британский возьмет скотч и скотч ;-)
Учитывая основной недостаток Питона — нелюбовь к многоядерным/многопроцессорным архитектурам

А у Матлаба что ли всё хорошо с многопоточностью/многопроцессорностью? Там вообще нет многопоточности на уровне m-языка, а мультипроцессинг убогий через parfor и MATLAB Parallel Server, с огромными накладными расходами на передачу данных и запуск процессов матлаба. numpy/scipy внутри себя освобождают gil и работают многопоточно.


SciPy не реализует ядро оптимизации, он использует древние проверенные фортрановские библиотеки, например NetLib, MINPACK и т. д. Их же использует Matlab. Думаю, вам как любителю фортрана знакомы эти названия.


На счет версий — это полная ерунда. Есть библиотеки, которые по 20 лет с версией 0.X и что же теперь ими пользоваться нельзя? Просто есть такая система версионирования. Называется ZeroVer 0-based Versioning.


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

В матлабе начина с 2017а с загрузкой процессора стало сильно лучше, но она на уровне матричных операций и индексирования. Ну и введение GPU arrays временами пригождается.
Спасибо за подробный комментарий, Вы все правильно говорите, единственно позволю себе некоторые уточнения.
«экономически просто нецелесообразна», т.е. машины на поездить или для посчитать целесообразны, а программное обеспечение нет. Странно немного.

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

Учить студентов Фортрану конечно можно, но начинать полезнее все-таки по принципу чем попроще, тем лучше.
«интерактивность и простой синтаксис» — а как бы у MATLAB/Maple/IRAF интерактивность повыше будет. Не?

Лично мне работа в Anaconda нравится намного больше MATLAB, но это конечно субъективно.
Для сравнения Linux 1.0 появился 25 лет назад и только последнее время Linux смог претендовать на нишу более менее надёжного швейцарского ножа.

Технологии совместной разработки сейчас получше, чем 25 лет назад, да и ядро Linux посложнее scipy будет. В любом случае, продукт не растет сам по себе, нужны усилия сообщества, нужно рассказывать пользователям, что есть альтернатива ворованному ПО.
В любом случае, продукт не растет сам по себе, нужны усилия сообщества
Собственное я ж это с самого начала и сказал: «NAG не очень подходит для юношей с горящим взором, которые, прямо таки сразу, желают внести свою лепту в теорию и/или практику вычислительной математики». А Вы писали — однобоко ;)
Учить студентов Фортрану конечно можно, но начинать полезнее все-таки по принципу чем попроще, тем лучше.
Проще что? Проще писать хорошие вычислительные модели на C/FORTRAN? Или проще быстрее начать и позже решить?

Как бы Питон авторы предназначали совсем для иного — сетевые сервисы, тот же DJANGO, администрирование, работа со сложно организованными текстовыми данным сравнительно небольшого объёма. Ещё визуалировать, рассортировать наблюдательные данные он ещё туда-сюда. Хотя с картинками от того же НАСА/LROC на сотни мегабайт он уже киснет и плачет.

Я вот смотрю на некоторые проекты и наблюдаю непонятное. Типа на одном процессоре всё медленно, считать не очень умеем, с многими процессорами не дружим. А давайте использовать MPI, использовать много вычислительных узлов. Мало того, заодно для преодолений ограничений Питона будем относится к соседним ядрам своего процессора как к удалённым узлам.

Не знаю, не знаю, пока Питон находится в парадигме своего основателя Гвидо ван Россума — «90% программ однопроцессорные и, по большому счёту, однопоточные». Всё будет странно устроено, к гадалке не ходи. Мне так кажется.
Очень хороший вопрос. К сожалению, готовых методик выбора алгоритма оптимизации я не встречал, а у самого пока мало опыта в решении подобных задач. Так что пока остается только перебор и интуиция.
Only those users with full accounts are able to leave comments. Log in, please.