Проблема с scipy.optimize.fmin_slsqp при использовании очень больших или очень маленьких чисел

Question

Кто-нибудь когда-либо сталкивался с проблемами с fmin_slsqp (или с чем-то еще в scipy.optimize) только при использовании очень больших или очень маленьких чисел?

Я работаю над кодом Python, чтобы взять изображение в градациях серого и маску, сгенерировать гистограмму, а затем подстроить несколько гауссианов к гистограмме. Для разработки кода я использовал небольшой пример изображения, и после некоторой работы код работал блестяще. Однако, когда я сначала нормализую гистограмму, генерируя значения bin <<1, или когда я гистограммирую огромные изображения, генерируя значения bin в сотнях тысяч, fmin_slsqp() начинает сбоить спорадически. Он выходит только после ~5 итераций, обычно просто возвращает слегка измененную версию первоначального предположения, которое я дал, и возвращает режим выхода 8, что означает "Положительная производная по направлениям для линейного поиска". Если я проверю размер количества бинов в начале и масштабирую их до ~100-1000, fmin_slsqp() работает как обычно. Я просто масштабирую вещи перед тем, как вернуть результаты. Я думаю, я мог бы оставить это так, но это похоже на взлом.

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

Джеймс

Answer 1

У меня были похожие проблемы optimize.leastsq. Данные, с которыми мне приходится иметь дело, часто очень малы, например, 1e-18 и т. Д., И я заметил, что leastsq не сходится к параметрам наилучшего соответствия в этих случаях. Только когда я масштабирую данные до чего-то более общего (например, сотнями, тысячами и т. Д., Что вы можете поддерживать разрешение и динамический диапазон с целыми числами), я могу позволить leastsq сходиться к чему-то очень разумному.

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

Кто-нибудь знает хороший общий подход, чтобы избежать этой проблемы с функциями в пакете scipy.optimize? Буду признателен, что вы могли бы поделиться... Я думаю, что корень та же проблема с ОП.

Answer 2

Обновляете ли вы свое первоначальное предположение ("x0"), когда ваши базовые данные резко меняются? для любой итеративной задачи линейной оптимизации эти проблемы возникнут, если ваше первоначальное предположение далеко от данных, которые вы пытаетесь уместить. Это скорее проблема оптимизации, чем проблема скипа.

Answer 3

У меня тоже были проблемы с этой проблемой, но я решил ее в своем проекте. Я не уверен, если это общее решение.

Причина была в том, что scipy.optimize.fmin_slsqp вычислил градиент по приближенному подходу, когда аргумент jac устанавливается False или по умолчанию. Градиент, полученный в результате приближенного подхода, не был нормализован (в больших масштабах). При расчете длины шага большое значение градиента будет влиять на производительность и точность поиска строк. Это может быть причиной того, что мы получили Positive directional derivative for linesearch,

Вы можете попытаться реализовать замкнутую форму матрицы Якоби для функции объекта и передать ее jac аргумент. Что еще более важно, вы должны изменить масштаб значения матрицы Якоби (например, нормализацию), чтобы избежать влияния на поиск строк.

Лучший.