Re: need just 6 digits
From: Patricia Shanahan (patricia_shanahan_at_earthlink.net)
Date: 03/26/05
- Next message: Darryl Pierce: "Re: J2ME, Canvas,"
- Previous message: Brian Munroe: "Re: Correct way to model a real world object"
- Maybe in reply to: polilop: "need just 6 digits"
- Next in thread: Patricia Shanahan: "Re: need just 6 digits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 26 Mar 2005 01:36:49 GMT
Thomas G. Marshall wrote:
> A 1.0 is cleanly represent by a double. So is a 3.0.
> That matters not in the least, because a 1.0 / 3.0 is
> not, and congruent to your argument: "the infinite
> precision result of dividing an integer by 3.0 can be
> represented in decimal with no more than 1 digit after
> the decimal point" is wrong, only because "represented in
> decimal" is not the issue. It's the values before it
> gets string converted.
My comment, although I specifically talked about division of
an integer by 1,000,000 in decimal, generally applies to
division of an integer by an integer power of the radix. If
R is a positive integer, J is an integer, and N is a
non-negative integer, using "**" to represent
exponentiation, J/(R**N) has no more than N digits in its
radix R expansion.
It is true for division of integers by powers of two in
binary, or powers of 16 in hexadecimal, or powers of ten in
decimal. It does not apply to division by 3 in decimal,
because 3 is not an integer power of 10.
Of course, 1/3 does have an exact one digit representation
in radix 3, "0.1".
> Dividing a 9123456.789 by a 1,000,000.D just might not
> nail precisely 9.123456 on all floating point
> implementations. This one *does* in java, as I've shown.
> I can experiment with an enormous loop and check the
> result lengths programmatically: unfortunately I'm out of
> time right at the moment.
I don't understand this comment. Are you claiming that
9.123456 is exactly representable as a Java double? It isn't.
> That's only if d is equally distant from the two. What
> if d is closest to 9.1234559999999999999? I argue that
> /that/ just may be the case *sometimes*, but do not know.
>
>
I think this may be the key point. Double.toString(d) does
not pick the the decimal expansion that is closest to d.
Because two is a factor of ten, and Java doubles, other than
NaNs and infinities, are binary fractions, each double
number is exactly equal to a terminating decimal fraction.
The exact equivalent would always be the closest decimal
number, but often has an inconveniently long fractional part.
Instead, Double.toString(d) picks the one with the fewest
digits in the fractional part from all the decimal fractions
that would round to d.
Suppose d is the double that results from the division, the
IEEE round-to-nearest of 9.12456.
Consider the set X of decimal fractions x_i for which d is
the double that would result from IEEE round-to-nearest
applied to x_i. 9.123456 is in X, because d was obtained
from it by IEEE round-to-nearest. X contains
9.1234559999999991219965522759594023227691650390625, the
exact decimal representation of d. 9.1234559999999999999 is
between those two numbers, so it must also be in X.
Incidentally, it is closer to d than 9.123456 is.
The rules I quoted from the API documentation force
Double.toString(d) to choose 9.123456 in preference to
9.1234559999999999999, or the even closer
9.1234559999999991219965522759594023227691650390625, because
9.123456 has fewer digits than either of them in its
fractional part.
Patricia
- Next message: Darryl Pierce: "Re: J2ME, Canvas,"
- Previous message: Brian Munroe: "Re: Correct way to model a real world object"
- Maybe in reply to: polilop: "need just 6 digits"
- Next in thread: Patricia Shanahan: "Re: need just 6 digits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
