> Hello everybody! I have the following question:
> Given a double number, can I calculate the next closest double that can
> represented from Java's float implementation ?
What? float or double?
> e.g. If I have the number
1.500000000000000000000000000000000000000011111111111000000000000000000000000000000000000000000000000000
> and the precision is
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
> then the next number would be
1.500000000000000000000000000000000000000011111111111000000000000000000000000000000000000000000000000001
floats have 7 digits precision, doubles have 15 digits precision. That is
TOTAL digits, not digits after the decimal point. That means, first number
would be 1.5, second number would be 0, and the third again 1.5
> Can I do something like this or the precision is not the same for all
> numbers?
Depends. relative precision is the same for all doubles/floats,
absolute precision (the one you seem to refer to) is not.
Have a look at java.lang.Math.ulp(double) or java.lang.Math.ulp(float).
If thats not what you want, have a look at java.math.BigDecimal.
kkyzir@gmail.com - 05 Oct 2006 14:05 GMT
Thanks Boris! I'm on to it
> Hello everybody! I have the following question:
> Given a double number, can I calculate the next closest double that can
[quoted text clipped - 10 lines]
>
> Thanks in advance!
The absolute value of the gap between adjacent doubles varies with
magnitude. Floating point carries a fixed number of significant bits, so
large numbers have bigger gaps between them than small numbers.
It is sometimes called the "ulp", unit in last place, of the number, and
is a useful concept in talking and thinking about floating point precision.
If you want to know it for a specific number, use Math.ulp().
In simple cases (not infinities, NaNs, Double.MAX_VALUE), you can find
the next double up by adding one to the bit pattern:
long bits = Double.doubleToLongBits(in);
double up = Double.longBitsToDouble(bits+1);
Patricia
kkyzir@gmail.com - 07 Oct 2006 15:10 GMT
Thank you Patricia for your answer! I had to read the IEEE 754 standard
to fully understand what you had already explained to me! It was
exactly what I was looking for!
Andrew Thompson - 07 Oct 2006 15:50 GMT
> Thank you Patricia for your answer! I had to read the IEEE 754 standard
> to fully understand what you had already explained to me! It was
> exactly what I was looking for!
I am still lost.*
What is the actual (/ultimate) purpose of gaining the next double?
* Not that that matters to the OP or their stated problem,
but I am interested.
Andrew T.
Patricia Shanahan - 07 Oct 2006 17:30 GMT
>> Thank you Patricia for your answer! I had to read the IEEE 754 standard
>> to fully understand what you had already explained to me! It was
[quoted text clipped - 6 lines]
> * Not that that matters to the OP or their stated problem,
> but I am interested.
I don't know about the OP's interest, but I am interested in the gaps
between adjacent numbers as a means to the end of understanding floating
point behavior.
The precision of many of the java.lang.Math methods is defined in terms
of the ulp for the input. The most accurate operations, including simple
arithmetic, produce an answer, if rounding is needed, that is one of the
pair of doubles that bracket the infinitely precise result.
Patricia
Patricia Shanahan - 07 Oct 2006 17:37 GMT
> Thank you Patricia for your answer! I had to read the IEEE 754 standard
> to fully understand what you had already explained to me! It was
> exactly what I was looking for!
You have my sympathy. What understanding I have of IEEE floating point
came partly from reading the standard, many times.
Patricia
Andrew Thompson - 07 Oct 2006 17:43 GMT
> > Thank you Patricia for your answer! I had to read the IEEE 754 standard
> > to fully understand what you had already explained to me! It was
> > exactly what I was looking for!
>
> You have my sympathy. What understanding I have of IEEE floating point
> came partly from reading the standard, many times.
(chuckle) BTW - Thanks for the response on the other (sub)thread.
Andrew T.