PS I've added your comment to bug 6667086 "Double.doubleToLongBits(final
double value) contains inefficient test for NaN."
-Joe
On 9/18/2011 6:15 PM, Joe Darcy wrote:
Hi Jeff.
I'll consider that for some possible future work.
Thanks,
-Joe
Jeff Hain wrote:
Hi.
There are some possible optimizations for some methods.
For nextAfter(double,double) (same for float version), instead of
testing NaN-ity right away,
we can test most common (or at least regular) cases first:
public static double nextAfter(double start, double direction) {
// Balancing out by branching to going-down case first,
// for it is heavier than going-up case (test if start is +-0.0).
if (start > direction) {
// Going down.
if (start == 0.0d) {
// start is +0.0 or -0.0
return -Double.MIN_VALUE;
}
final long transducer = Double.doubleToRawLongBits(start);
assert transducer != 0L;
return Double.longBitsToDouble(transducer + ((transducer >
0L) ? -1L:1L));
} else if (start < direction) {
// Going up.
// Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0)
// then bitwise convert start to integer.
final long transducer = Double.doubleToRawLongBits(start +
0.0d);
return Double.longBitsToDouble(transducer + ((transducer >=
0L) ? 1L:-1L));
} else if (start == direction) {
return direction;
} else { // start and/or direction is NaN
return start + direction;
}
}
Same for nextUp(double) and float version (also, testing transducer
>= 0L
instead of d >= 0.0D seems to help):
public static double nextUp(double d) {
if (d < Double.POSITIVE_INFINITY) {
final long transducer = Double.doubleToRawLongBits(d + 0.0D);
return Double.longBitsToDouble(transducer + ((transducer >=
0L) ? 1L:-1L));
} else { // d is NaN or +Infinity
return d;
}
}
-Jeff
------------------------------------------------------------------------
*De :* "joe.da...@oracle.com" <joe.da...@oracle.com>
*À :* core-libs-dev <core-libs-dev@openjdk.java.net>
*Envoyé le :* Samedi 17 Septembre 2011 3h52
*Objet :* JDK 8 code review request for 7091682 "Move
sun.misc.FpUtils code into java.lang.Math"
Hello.
Please review the changes to address
7091682 "Move sun.misc.FpUtils code into java.lang.Math"
http://cr.openjdk.java.net/~darcy/7091682.0/
<http://cr.openjdk.java.net/%7Edarcy/7091682.0/>
As implied by the synopsis, where appropriate JDK-implementation code
used to provide functionality in java.lang.Math and
java.lang.StrictMath is moved out of sun.misc.* and into
java.lang.Math. Uses of methods available in java.lang.Math and
switched to that entry point as opposed to the sun.misc one.
Additionally, the sun.misc methods whose implementation was moved
were also deprecated.
Later in JDK 8, I will probably add some of the remaining
un-deprecated methods in sun.misc.FpUtils as
java.lang.Math/StrictMath methods.
Thanks,
-Joe
