Мой fma() сломан?

это вина Cygwin. Или, вернее,newlib библиотека C используется. Это явно говорит он даже не пытается сделать fma() эмуляция корректная.

библиотека GNU C имеет правильную эмуляцию почти для всех вариантов fma с 2015 года. Дополнительные сведения и исправления, используемые для реализации этого, см. В разделе ошибка sourceware 13304.

если эффективность не является проблемой, то я бы просто использовал, например,

#if defined(__CYGWIN__) && !defined(__FMA__) && !defined(__FMA3__) && !defined(__FMA4__)
#define fma(x, y, z)  fma_emulation(x, y, z)

double fma_emulation(double x, double y, double z)
{
    /* One of the implementations linked above */
}
#endif

Я не лично использовать Windows вообще, но если кто-то делает (используйте Windows и нужна эмуляция fma), я бы предложил им попробовать и нажать патч вверх по течению, со ссылкой на Обсуждение Библиотеки GNU C о правильной эмуляции fma.

что мне интересно, можно ли было бы изучить только низкие M биты результата (отбрасываются при округлении) для определения правильного значения ULP в результате и корректировки полученного результата с помощью прямой a×b+c операции таким образом, используя nextafter(); вместо использования многовариантной арифметики для реализации всей операции.

Edit: нет, потому что добавление может переполниться, отбросив дополнительный бит как MSB отброшенной части. Только по этой причине мы должны провести всю операцию. Другая причина в том, что if a×b и c имеют разные знаки, то вместо сложения мы вычитаем меньшее по величине из большего по величине (результат с использованием знака большего), что может привести к очистке нескольких высоких битов в большем, и это влияет на то, какие биты всего результата отбрасываются в округлении.

однако для IEEE-754 Binary64 double на архитектурах x86 и x86-64 я считаю, что эмуляция fma с использованием 64-битных (целочисленных) регистров и 128-битного продукта по-прежнему вполне возможна. Я буду экспериментировать на представлении, где низкие 2 бита в 64-битном регистре используются для округления битов решения (LSB является логическим или всех отброшенных битов), 53 бита, используемых для мантиссы, и один бит переноса, оставляя 8 неиспользуемых и игнорируемых высоких битов. Округление выполняется, когда целое число без знака мантисса преобразуется в (64-разрядный) двойной. Если эти эксперименты дадут что-нибудь полезное, я опишу их здесь.

первоначальные выводы: fma() эмуляция в 32-разрядной системе происходит медленно. 80-битный материал на 387 FPU в основном бесполезен здесь, и реализация 53×53-битного умножения (и битового сдвига) в 32-битной системе справедлива .. не стоит усилий. В glibc fma() код эмуляции, связанный с выше, на мой взгляд, достаточно хорош.

дополнительные выводы: обработка конечных значений гадость. (Субнормалы лишь слегка раздражают, требуя специальной обработки (поскольку неявный MSB в мантиссе равен нулю).) Если любой из трех аргументов не является конечным (бесконечность или какая-то форма NaN), затем возвращение a*b + c (не сплавленный) единственный здравый вариант. Обработка этих случаев требует дополнительного ветвления, что замедляет эмуляцию.

окончательное решение: количество случаев для обработки оптимизированным способом (а не с использованием многовариантного подхода "конечности", используемого в эмуляции glibc) достаточно велико, чтобы сделать этот подход не стоит усилий. Если каждая конечность 64-битная, каждая из a, b и c это растяните не более 2 конечностей, и a×b в течение трех конечностей. (С 32-битными конечностями, то есть всего 3 и 5 конечностей, соответственно.) В зависимости от того,a×b и c имеют те же или разные знаки, есть только два принципиально разных случая для обработки-в случае разных знаков сложение превращается в вычитание (меньше от большего, результат получает тот же знак, что и большее значение).

In короче говоря, подход multiprecision лучше. Фактическая необходимая точность очень хорошо ограничена и не требует даже динамического распределения. Если произведение мантисс a и b смогите быть высчитано эффективно, часть multiprecision ограничена к держать продукт и регулировать добавление/вычитание. Окончательное округление может быть выполнено путем преобразования результата в 53-битную мантиссу, экспоненту и два дополнительных низких бита (чем выше, тем значительнее бит потерянный в округлении, а нижний-или из остальных битов, потерянных в округлении). По сути, ключевые операции могут выполняться с использованием целых чисел (или регистров SSE/AVX), а окончательное преобразование из 55-битной мантиссы в double обрабатывает округление в соответствии с текущими правилами.