Hi Andrew,
On 12/19/2016 7:24 AM, Andrew Haley wrote:
On 15/12/16 20:25, joe darcy wrote:Hello, Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp: JDK-8139688 Port fdlibm exp to Java http://cr.openjdk.java.net/~darcy/8139688.5/ Same methodology followed as when porting the earlier functions.As discussed, this test is pointless because it is always true: + if(huge+x>one) return one+x;/* trigger inexact */ I understand that we intend to leave the code untouched, but the inexact flag has no effect in Java code. Does it really make sense to translate the code to Java but include such cruft?
It may not be clearly evident from the code reviews, but I take an iterative approach to porting the fdlibm C code to Java. The first iteration is the "transliteration" step where code as close to the C code is used and checked into the regression tests as a reference. I test the regression tests at this point by running them against JDK 8 which is still using the C version of fdlibm.
Once that is done, I'll make a number of passes over a copy of the transliterated code in the core area to get it closer to idiomatic Java, sane whitespace and indenting, use of hex floating-point constants for specific values, preferring floating-point vs integer-based value checks, etc. One of those passes is removing "extraneous" computations which are present to set the IEEE floating-point flags, which as you point out, are outside of the Java and JVM model of computation.
With deadlines looming, I didn't get to all the cruft removal passes for exp, but that can be done as future work.
Cheers, -Joe
