Точность превыше всего!

[green_fr]

На работе использую программу для генерирования экономических сценариев (B+H ESG), при определённой конфигурации она вылетает с нечитаемой ошибкой. Hotline объясняет, что у меня данные неправильные, моя матрица должна быть положительно полуопределённой, бла-бла-бла.

Я проверяю — одно из собственных значений выходит −2E-16.
Формально да, отрицательное. Но мы все понимаем, что это ноль, проблема округления (более того, я могу с ручкой на бумажке доказать, что это ноль, я намеренно сделал вырожденную матрицу, мне так надо).

Весь день бодаюсь теперь с hotline’ом по почте, доказывая, что это не «extremely high degree of accuracy in calculations» (цитата из их ответа), а баг, требующий патча. Ищу понятные аргументы...

Update: победили, ошибку признали, постараются когда-нибудь починить, но уже точно не успеют к следующей (7.3.0) версии.

Comments

[french-man.livejournal.com]

Собственно, сколько б ни было. Добавь к своей матрице 10^-15I, и дело с концом.

[dmpogo.livejournal.com]

Не обязательно сработает. Точнее сработает но ответ может быть с мусорком, поскольку обращение (в зависимости от алгоритма) будет зависить от 'machine precision' если епсилон мало (а 10^-15 очень близко к double precision), и менять результат если велико. По честному тут надо прогнать несколько значений добавленного малого числа и посмотреть что ответ не зависит.

[green-fr.livejournal.com]

Это double precision на величинах порядка единицы, она там относительная. Это моя любимая иллюстрация проблемы округления, перед написанием поста показывал своим коллегам (они ни разу не программисты, они не в курсе), что
1E-50 + 1 - 1
Это совсем не то же самое, что
1E-50 + (1 - 1)
Так чт надо ещё в голове держаить абсолютные величины, но я как раз с процентами работаю, там всё порядка единицы крутится, поэтому и бросаются в глаза "родные" 1E-15.

[green-fr.livejournal.com]

Ты не поверишь, но именно это они и предлагают. В принципе, сдаётся мне, этим всё и кончится, но пока что мне чисто по-человечески лень. Я всю эту затею нача.л из-за того, что мне лень было терять время на генерирование сценариев для 100% корелированных портфелей. Я ввёл их отдельно (откуда одинаковые строки в матрице), чтобы одним генерированием получать сразу всё.
Если сделать эти портфели коррелирующими на 99.999999%, то тестировать придётся более основательно (а не просто тупо сравнить посимвольно файлы и убедиться в их идентичности), то есть я проиграю больше времени, чем выиграю. Я посчитал, что генерирование закончится в понедельник к полудню, а раньше я всё равно кофе не допью, можно не спешить.
Но в долгосрочной перспективе да, придётся вводить "прчти абсолютно корелирующие активы", бред какой-то....

[french-man.livejournal.com]

Естественней было бы их попросить заменить условие положительности на «почти положительности». Но если они на это не идут, то другого варианта я не вижу.

[green-fr.livejournal.com]

Ты видел, я исправил — матрица изначально требуется положительно полуопределённой, я вначале опечатался. То есть по условиям нули проходят, конечно же. Вопрос — считать ли −2E-16 нулём или нет, такой тонкий стык между математикой и информатикой :-)

[dolganoff.livejournal.com]

А какова вероятность того, что кому-то из их клиентов будет важно различать числа по модулю меньше 2E-16? Может для кого-то это уже достаточно большие числа, а вы их к нулю приравнивать собрались?

[green-fr.livejournal.com]

Никакая, это матрица корреляций, а не массы электронов :-)