Hello Aleksej,
Looking at the code, I have another suggestion. If this code can run
exclusively on JDK 8 or later, replace
955 if (Double.isNaN(d) || Double.isInfinite(d))
956 return(Double.toString(d));
with
955 if (!Double.isFinite(d))
956 return(Double.toString(d));
Cheers,
-Joe
On 6/9/2013 11:18 AM, Aleksej Efimov wrote:
Joe,
I definitely like it:
1. Its a one-line change - perfect size.
2. Its fastest one from discussed previously.
3. -0.0 -> 0.0 has tests.
4. And it solves our problem.
As a result of all props the next version of webrev:
http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.8015978.v2/>
Thanks
-Aleksej
On 06/07/2013 11:11 PM, huizhe wang wrote:
Nice. One-line change, I guess Aleksej would love it :-)
On 6/7/2013 10:19 AM, Joe Darcy wrote:
I'll do you one better; you can turn a negative zero into a positive
zero leaving other values unchanged like this:
d = d + 0.0;
In IEEE 754 under the round-to-nearest-even rounding mode required
by Java
-0.0 + 0.0 => (+)0.0
This trick is used in various places in Java's numerical libraries,
is required behavior by our specifications, and even has some tests
for it :-)
-Joe
On 6/7/2013 8:43 AM, David Chase wrote:
Wouldn't be more efficient to do the following, assuming that the
full Java compilation chain respects the trickiness of 0 vs -0:
if (d == 0.0) {
d=0.0 // Jam -0 == +0 to +0, per
http://www.w3.org/TR/xpath/#function-string
}
Division's plenty more expensive than assigning a constant,
especially on platforms that lack hardware FP division.
David
On 2013-06-07, at 2:03 AM, huizhe wang <huizhe.w...@oracle.com> wrote:
Hi Aleksej,
According to XPath spec, both positive and negative zero are
converted to the string 0, so it seems doesn't matter. But if you
want to detect the negative zero, you may do the following:
if (d == 0.0 && 1/d < 0.0) {
d=0.0
}
Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity).
-Joe
