double vs long serialization in java

Question

I can store a number as a Long and Double in HBase. Both of them takes 8 bytes in Java.

Advantage of Using Double is that it gives a more wider range for storing Whole Numbers.

However, i think range of Long is also enough for my use.

Does anyone has any idea about the serialization and de-serialization performance of Long vs Dobule? I am interested in comparison between them.

Thanks.

Answer 1

If you are storing integers, use Long. Your statement that "Advantage of Using Double is that it gives a more wider range for storing Whole Numbers" is incorrect. Both are 64 bits long, but double has to use some bits for the exponent, leaving fewer bits to represent the magnitude. You can store larger numbers in a double but you will lose precision.

In other words, for numbers larger than some upper bound you can no longer store adjacent "whole numbers"... given an integer value above this threshold, the "next" possible double will be more than 1 greater than the previous number.

For example

public class Test1  
{

    public static void main(String[] args) throws Exception 
    {
        long   long1 = Long.MAX_VALUE - 100L;
        double dbl1  = long1;
        long   long2 = long1+1;
        double dbl2  = dbl1+1;
        double dbl3  = dbl2+Math.ulp(dbl2);

        System.out.printf("%d %d\n%f %f %f", long1, long2, dbl1, dbl2, dbl3);
    }

}

This outputs:

9223372036854775707 9223372036854775708
9223372036854776000.000000 9223372036854776000.000000 9223372036854778000.000000

Note that

1. The double representation of Long.MAX_VALUE-100 does NOT equal the original value
2. Adding 1 to the double representation of Long.MAX_VALUE-100 has no effect
3. At this magnitude, the difference between one double and the next possible double value is 2000.

Another way of saying this is that long has just under 19 digits precision, while double has only 16 digits precision. Double can store numbers larger than 16 digits, but at the cost of truncation/rounding in the low-order digits.

If you need more than 19 digits precision you must resort to BigInteger, with the expected decrease in performance.