This is hard to do exactly right... The JDK code does stuff with rational arithmetic and so forth. We use a much simpler algorithm which may give an answer off in the lowest order bit. Since this is pure Java, it should still be consistent from machine to machine.

Recall that the binary representation of the double is of the form d = 0.bbbbbbbb x 2ⁿ where there are up to 53 binary digits in the binary fraction (including the assumed leading 1 bit for normalized numbers). We find a value m such that 10^m d is between 2⁵³ and >2⁶³. This product will be exactly convertible to a long with no loss of precision. Getting the decimal representation for that is trivial (see formatLong). This is a decimal mantissa and we have an exponent (-m). All we have to do is manipulate the decimal point to where we want to see it. Errors can arise due to roundoff in the scaling multiplication, but should be no more than a single bit.

This is hard to do exactly right... The JDK code does stuff with rational arithmetic and so forth. We use a much simpler algorithm which may give an answer off in the lowest order bit. Since this is pure Java, it should still be consistent from machine to machine.

Recall that the binary representation of the float is of the form d = 0.bbbbbbbb x 2ⁿ where there are up to 24 binary digits in the binary fraction (including the assumed leading 1 bit for normalized numbers). We find a value m such that 10^m d is between 2²⁴ and >2³². This product will be exactly convertible to an int with no loss of precision. Getting the decimal representation for that is trivial (see formatInteger). This is a decimal mantissa and we have an exponent (-m). All we have to do is manipulate the decimal point to where we want to see it. Errors can arise due to roundoff in the scaling multiplication, but should be very small.