Mike Kaganski
d32c664c3d
01:26,47 is 0.001000810185185185, which has 16 significant decimals. It is converted to string as "0.00100081018518519" (15 significands). The problem was, that when criterion "=0.00100081018518519" is used to check value 0.001000810185185185, the two numbers differ in five least significant bits, but rtl_math_approxEqual uses 0x1p-48 to ignore last four bits only. This is a common problem for numbers close to 1.0E(N). This change introduces a second threshold, in addition to "only take into account 48 signigicant bits of mantissa": it calculates the value of half of 15th decimal unit of the smaller absolute value, and uses the greater of the two thresholds for the approximate equality. Change-Id: I2f98ab23c94ca3a2949c3762fbfb6ea563eef94b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191883 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
System Abstraction Layer (SAL)
System abstraction layer; rtl, osl and sal
rtl:
Platform independent strings
osl:
platform specific stuff, threads, dynamic loading, process, ipc, etc
Exports only C API and some inline-methods (only C++ API).