[OE-core] libm accuracy, eglibc compared to glibc

[Mats Kärrman]

On Wednesday, March 12, 2014 4:58 PM, Burton, Ross wrote:
> On 12 March 2014 15:30, Mats Kärrman <Mats.Karrman at tritech.se> wrote:
>> Does anyone know if this is a known "feature" of eglibc or know any other reason
>> for this difference?
>
> I expect the standard response from upstream here would be that
> floating point mathematics isn't exact and if you want exact answers
> then you should use a different representation. The differences start
> at the first sqrt():
> 
> Test 1 and 2:
> sqrt(2.00000000000000000000) = 1.41421356237309514547
> Test 3:
> sqrt(2.00000000000000000000) = 1.41421356237309492343
> Test using bc and scale=30 (bc is fixed-point not floating-point):
> sqrt(2.00000000000000000000) = 1.414213562373095048801688724209
> 
> The output from bc is a truncation of the "real" value of sqrt(2)
> whereas both values from C's sqrt() function using floats are
> approximations, both equally close.  Why does your test case expect
> the answer to be 2.0?  That's a massive assumption to make, floats can
> trivially lose accuracy rapidly as
> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
> explains.

I am aware of the problems with floating point math. The test cases are from IBM
and used to validate their J9 JVM on new platforms. AfaIk they normally work (as
they do for my old OE-classic system and for my Debian PC).

Any reason that EGLIBC should be different from GLIBC?

// Mats