On Wednesday, March 12, 2014 4:58 PM, Burton, Ross wrote: > On 12 March 2014 15:30, Mats Kärrman <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
