Re: yet another Java oddity

[CdeMills]

Mike Miller-2 wrote
> Yes, well aware of floating point representation. Regardless glibc's
> libm *does* return the exact binary significand such that 1e-5 ==
> std::pow(10, -5), and some of the tests in Octave have been relying on
> that until this point. We can certainly change some of the tests to add
> tolerances, which falls under what I said:
> 
>>> Either by addressing the underlying bug/feature or
>>> by tweaking those particular routines that are failing.

I didn't know about this glibc feature. Another option would be to compute
what's exactly behind 10^-5 before and after jvm is loaded:
x1 = [1e-5 10^-5]; x1 = [x1 log2(x1)];
%# load java 
x2 = [1e-5 10^-5]; x2 = [x2 log2(x2)];

If there are troubles, the figures should be somewhat different on the
latest decimals. The culprit may either be in the number parser, either in
the std::pow operation.

Regards

Pascal



--
View this message in context: 
http://octave.1599824.n4.nabble.com/yet-another-Java-oddity-tp4649593p4649612.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.