Проблема с scipy.optimize.fmin_slsqp при использовании очень больших или очень маленьких чисел - PullRequest
5 голосов
/ 17 февраля 2011

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

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

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

Джеймс

Ответы [ 3 ]

5 голосов
/ 06 декабря 2011

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

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

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

4 голосов
/ 17 апреля 2011

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

1 голос
/ 01 декабря 2015

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

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

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

Best.

...