Внезапно потребовалось, чтобы в реализации результат численного расчета на одинаковых входных данных был (бинарно) тождественным, независимо от машины на которой проводился расчет.
Следую рекомендациям из https://www.eucass.eu/doi/EUCASS2019-0790.pdf . (Настройка округления, флаги компилятора и т.д.)

Однако, воспроизводимости добиться не удалось.
Выяснилось что в различие в цепочке промежуточных расчетов появляется при вызове функции double std::exp(double), которая реализована в libm.so, и дает немножко разный результат для разных версий libm.

	сравнение
	считаю значение exp(-9.2935498391158440e+00) флаг округления FE_TONEAREST (по умолчанию) FE_DOWNWARD FE_UPWARD FE_TOWARDZERO libm 2.31 9.2015838408730848e-05 9.2015838408730834e-05 9.2015838408730848e-05 9.2015838408730834e-05 libm 2.28 9.2015838408730834e-05 9.2015838408730834e-05 9.2015838408730834e-05 9.2015838408730834e-05

Прилинковать libm статически — не удалось. (Она де-юре является частью libc, а его не удалось прилинковать статически к *.so.)

Вопрос: Где можно найти альтернативную реализацию базовых математических функций, чтобы заменить libm?
В boost.math, в числе спец функций как-раз exp отсутствует.

Здравствуйте, Chorkov, Вы писали:

C>Вопрос: Где можно найти альтернативную реализацию базовых математических функций, чтобы заменить libm?
Тут смотрели
https://www.netlib.org/cephes/

Здравствуйте, Chorkov, Вы писали:

C>Внезапно потребовалось, чтобы в реализации результат численного расчета на одинаковых входных данных был (бинарно) тождественным, независимо от машины на которой проводился расчет.

Используем musl как раз из-за такой необходимости.

Здравствуйте, Chorkov, Вы писали:

C>Вопрос: Где можно найти альтернативную реализацию базовых математических функций, чтобы заменить libm?

А почему просто не взять исходники того варианта exp из glibc который вас устраивает?

Отчет об использовании советов:


cephes:
оказалась очень недоработанной. Файлу unix.mak для сборки файлов не хватает (нужные файлы есть в других архивах с того же сайта, но некоторые файлы в разных архивах-разные и т.д.) Пару часов ушло на доработку напильником.

Производительность снизилась на 12%, в сравнении с libm из стандартной поставки ubuntu (glibc 2.31).
(Хотя решение пошло по другому пути и, возможно, эксперимент не чистый, число сделанных алгоритмом шагов — отличается на 0.7%.)

Еще подводный камень: прилинковывать её нужно не к вызывающему исполняемому файлу, а не к *.so файлу. (Из-за особенностей загрузчика linux).
Но для моего эксперимента это оказалось только удобнее.

Еще минус — совершенно непонятно что у нее с лицензией.


musl:
удобен если нужно заменить всю стандартную библиотеку. Выделить отдельный файл, например, только функцию exp — сложнее.
Если понадобится тащить версию с воспроизводимым результатом в продакшен — буду смотреть именно в эту сторону.


glibc:
выделение нужных функций из исходника — оказалось гораздо сложнее чем в случае cephes, а залинковать статически только математическую бублиотеку (libm.а + libc.so) — нельзя.
Можно собрать (вызывающий exe) со статически залинкованным libc. и это работает, но на ограниченном числе линуксов. (Т.е. в продакшен — нельзя.)