Відносне порівняння чисел з плаваючою комою

У мене є числова функція, що f(x, y)повертає подвійне число з плаваючою комою, яке реалізує певну формулу, і я хочу перевірити, чи правильно воно проти аналітичних виразів для всіх комбінацій параметрів xі yщо мене цікавить. Який правильний спосіб порівняння обчислених та аналітичні числа з плаваючою комою?

Скажімо, два числа є aі b. Поки я переконався, що як абсолютні ( abs(a-b) < eps), так і відносні ( abs(a-b)/max(abs(a), abs(b)) < eps) помилки менше, ніж eps. Таким чином він виявить числові неточності, навіть якщо цифри, скажімо, будуть приблизно 1e-20.

Однак сьогодні я виявив проблему, числове значення aта аналітичне значення bбули:

In [47]: a                                                                     
Out[47]: 5.9781943146790832e-322

In [48]: b                                                                     
Out[48]: 6.0276008792632078e-322

In [50]: abs(a-b)                                                              
Out[50]: 4.9406564584124654e-324

In [52]: abs(a-b) / max(a, b)                                                  
Out[52]: 0.0081967213114754103

Тож абсолютна помилка [50] (очевидно) мала, але відносна похибка [52] велика. Тому я подумав, що у мене в програмі помилка. За допомогою налагодження я зрозумів, що ці числа денормальні . Як такий, я написав таку процедуру, щоб зробити належне порівняльне порівняння:

real(dp) elemental function rel_error(a, b) result(r)
real(dp), intent(in) :: a, b
real(dp) :: m, d
d = abs(a-b)
m = max(abs(a), abs(b))
if (d < tiny(1._dp)) then
    r = 0
else
    r = d / m
end if
end function

Де tiny(1._dp)повертається 2.22507385850720138E-308 на мій комп'ютер. Тепер все працює, і я просто отримую 0 як відносну помилку, і все в порядку. Зокрема, вищезгадана відносна помилка [52] є помилковою, вона просто викликана недостатньою точністю денормальних чисел. Чи rel_errorправильна моя функція? Чи потрібно просто перевірити, що abs(a-b)менше крихітного (= денормальне), і повернути 0? Або я повинен перевірити якусь іншу комбінацію, наприклад max(abs(a), abs(b))?

Я просто хотів би знати, що таке "правильний" шлях.

Ви можете безпосередньо перевірити денормалізованних чисел , використовуючи isnormal()з math.h(C99 або більш пізньої версії, POSIX.1 або більш пізньої версії). У Fortran, якщо модуль ieee_arithmeticдоступний, ви можете використовувати ieee_is_normal(). Щоб бути більш точним щодо нечіткої рівності, ви повинні розглянути представлення плаваючої точки деннормалів і вирішити, що ви маєте на увазі, щоб результати були досить хорошими.

Більше того, щоб вважати, що будь-який результат правильний, ви повинні бути впевнені, що ви не втратили занадто багато цифр на проміжному кроці. Обчислення з деннормалами, як правило, недостовірне, і цього слід уникати, якщо алгоритм міняє внутрішню шкалу. Для того, щоб ваше внутрішнє масштабування було успішним, я рекомендую активувати винятки feenableexcept()з плаваючою комою, використовуючи C99 або ieee_arithmeticмодуль у Fortran.

Хоча ви можете змусити вашу програму вловлювати сигнал, який піднімається за винятками з плаваючою комою, всі ядра, які я намагався скинути прапор обладнання fetestexcept(), не приносять корисного результату. При запуску -fp_trapпрограми PETSc (за замовчуванням) надрукують слід стека, коли помилка з плаваючою точкою буде підвищена, але не буде ідентифікувати рядок порушень. Якщо ви працюєте в налагоджувальній машині, налагоджувач зберігає апаратний прапор і порушується на образливий вираз. Ви можете перевірити точну причину, зателефонувавши fetestexceptз налагоджувача, де результатом є побітове АБО наступних прапорів (значення можуть залежати від машини, див fenv.h. Ці значення для x86-64 з glibc).

• FE_INVALID = 0x1
• FE_DIVBYZERO = 0x4
• FE_OVERFLOW = 0x8
• FE_UNDERFLOW = 0x10
• FE_INEXACT = 0x20

Дональд Кнут має пропозицію щодо алгоритму порівняння з плаваючою комою у томі 2 «Напівлінійні алгоритми» «Мистецтва комп’ютерного програмування». Він був реалізований в C Th. Зварювання (див. Пакет fcmp ) і доступне в GSL .

Оптимально округлені денормалізовані числа дійсно можуть мати високу відносну похибку. (Скидання цього до нуля, все ще називаючи відносну помилку, вводить в оману.)

Але близько до нуля обчислювати відносні помилки безглуздо.

Тому, навіть перш ніж досягти денормалізованих цифр, ви, ймовірно, повинні перейти на абсолютну точність (а саме на ту, яку ви хочете гарантувати в цьому випадку).

Тому я б запропонував протестувати обчислені $y$$x$$|y-x|\le absacc+relacc*\max(|x|,|y|)$

Тоді користувачі вашого коду точно знають, скільки точності вони мають.