java - IEEE-754 double (64-bit floating point) vs. long (64-bit integer) revisited - Stack Overflow

admin管理员组

文章数量:1313738

I'm revisiting a question (How to test if numeric conversion will change value?) that as far as I was concerned was fully solved. The problem was to detect when a particular numeric value would overflow JavaScript's IEEE-754 Number type. The previous question was using C# and the marked answer worked perfectly.

Now I'm doing the exact same task but this time in Java and it doesn't work. AFAIK, Java uses IEEE-754 for its double data type. So I should be able to cast it back and forth to force the loss of precision but it round trips. Baffled by this I started poking deeper in Java and now I'm really confused.

In both C# and Java, the min and max values for long are the same:

long MIN_VALUE = -9223372036854775808L;
long MAX_VALUE = 9223372036854775807L;

AFAIK, these values are outside the representable numbers in IEEE-754 because of the fixed bits reserved for the exponent and sign.

// this fails in browsers that have stuck with the pure ECMAScript Number format
var str = Number(-9223372036854775808).toFixed();
if ("-9223372036854775808" !== str) { throw new Error("Overflow!"); }

This returns false for (value = -9223372036854775808L) in Java:

boolean invalidIEEE754(long value) {
    try {
        return ((long)((double)value)) != value;
    } catch (Exception ex) {
        return true;
    }
}

This returns false for (value = -9223372036854775808L) in Java:

boolean invalidIEEE754(long value) {
    // trying to get closer to the actual representation and
    // being more explicit about conversions
    long bits = Double.doubleToLongBits(Long.valueOf(value).doubleValue());
    long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();
    return (value != roundtrip);
}

This returns true for (value = -9223372036854775808L) but is less accurate:

boolean invalidIEEE754(long value) {
    return (0x0L != (0xFFF0000000000000L & (value < 0L ? -value : value)));
}

Why does this work this way? Am I missing something like piler optimization, e.g. is the piler detecting my conversions and "fixing" them for me?

Edit: Adding test case by request. All three of these tests fail:

import static org.junit.Assert.*;
import org.junit.Test;

public class FooTests {

    @Test
    public void ieee754One() {
        assertTrue(((long)((double)Long.MIN_VALUE)) != Long.MIN_VALUE);
    }

    @Test
    public void ieee754Two() {
        long bits = Double.doubleToLongBits(Long.valueOf(Long.MIN_VALUE).doubleValue());
        long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();

        assertTrue(Long.MIN_VALUE != roundtrip);
    }

    @Test
    public void ieee754Three() {
        long bits = Double.doubleToRawLongBits(Long.valueOf(Long.MIN_VALUE).doubleValue());
        long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();

        assertTrue(Long.MIN_VALUE != roundtrip);
    }
}

I'm revisiting a question (How to test if numeric conversion will change value?) that as far as I was concerned was fully solved. The problem was to detect when a particular numeric value would overflow JavaScript's IEEE-754 Number type. The previous question was using C# and the marked answer worked perfectly.

Now I'm doing the exact same task but this time in Java and it doesn't work. AFAIK, Java uses IEEE-754 for its double data type. So I should be able to cast it back and forth to force the loss of precision but it round trips. Baffled by this I started poking deeper in Java and now I'm really confused.

In both C# and Java, the min and max values for long are the same:

long MIN_VALUE = -9223372036854775808L;
long MAX_VALUE = 9223372036854775807L;

AFAIK, these values are outside the representable numbers in IEEE-754 because of the fixed bits reserved for the exponent and sign.

// this fails in browsers that have stuck with the pure ECMAScript Number format
var str = Number(-9223372036854775808).toFixed();
if ("-9223372036854775808" !== str) { throw new Error("Overflow!"); }

This returns false for (value = -9223372036854775808L) in Java:

boolean invalidIEEE754(long value) {
    try {
        return ((long)((double)value)) != value;
    } catch (Exception ex) {
        return true;
    }
}

This returns false for (value = -9223372036854775808L) in Java:

boolean invalidIEEE754(long value) {
    // trying to get closer to the actual representation and
    // being more explicit about conversions
    long bits = Double.doubleToLongBits(Long.valueOf(value).doubleValue());
    long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();
    return (value != roundtrip);
}

This returns true for (value = -9223372036854775808L) but is less accurate:

boolean invalidIEEE754(long value) {
    return (0x0L != (0xFFF0000000000000L & (value < 0L ? -value : value)));
}

Why does this work this way? Am I missing something like piler optimization, e.g. is the piler detecting my conversions and "fixing" them for me?

Edit: Adding test case by request. All three of these tests fail:

import static org.junit.Assert.*;
import org.junit.Test;

public class FooTests {

    @Test
    public void ieee754One() {
        assertTrue(((long)((double)Long.MIN_VALUE)) != Long.MIN_VALUE);
    }

    @Test
    public void ieee754Two() {
        long bits = Double.doubleToLongBits(Long.valueOf(Long.MIN_VALUE).doubleValue());
        long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();

        assertTrue(Long.MIN_VALUE != roundtrip);
    }

    @Test
    public void ieee754Three() {
        long bits = Double.doubleToRawLongBits(Long.valueOf(Long.MIN_VALUE).doubleValue());
        long roundtrip = Double.valueOf(Double.longBitsToDouble(bits)).longValue();

        assertTrue(Long.MIN_VALUE != roundtrip);
    }
}

• java
• javascript
• double
• long-integer
• ieee-754

Share Improve this question Follow edited Apr 19, 2021 at 0:51 phuclv 42k1515 gold badges182182 silver badges524524 bronze badges asked Dec 3, 2010 at 19:28 mckameymckamey 17.5k1616 gold badges8686 silver badges118118 bronze badges 4

• Both methods return false for me. JDK 1.6.0_21. – axtavt Commented Dec 3, 2010 at 19:37
• Interesting! Now I'm really confused. Mine is running via JUnit but should be on JDK 1.6.0_21 as well. – mckamey Commented Dec 3, 2010 at 19:42
• Can you show the full testcase?. – axtavt Commented Dec 3, 2010 at 19:49
• Sorry I had the true/falses swapped! Too many not-not's when talking about this. Sorry for the confusion. Your results are the same as mine. – mckamey Commented Dec 3, 2010 at 20:00

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 6

-9223372036854775808L is representable as an IEEE-754 double-precision number. It is exactly -2^63, which has the double representation -1.0 x 2^63 and encoding 0xc3e0000000000000.

Double is capable of representing numbers much, much larger than this. However, it is not capable of representing all integers in the range of representable numbers. For example, if you add one to the number, you will get -9223372036854775807 = -2^63 + 1, which is not representable as a double-precision value, and will not survive the round-trip conversion.

Converting -2^63 + 1 to double will round it to the nearest representable double value, which is -2^63; conversion back to long will preserve that value.

Edit: What platform did you do you JavaScript test on? In current Safari,

"-9223372036854775808" === Number(-9223372036854775808).toFixed()

evaluates as True.

本文标签： javaIEEE754 double (64bit floating point) vs long (64bit integer) revisitedStack Overflow