Chris said:
I'll point out that while you and Patricia are right, the other
responses you got aren't as dumb as you seem to think. Specifically, no
information at all was lost in that display under the following two
assumptions:
(a) you understand a floating point value as representing a range of
possible mathematical values, as Chris Uppal pointed out; AND
There are three problems with regarding a floating point number as
representing a range of possible mathematical values rather than as
corresponding to a unique real:
1. It conflicts with both the JLS and ANSI/IEEE Std 754-1985. Each gives
a formula for calculating the real number value of a floating point
number, based on the values of its bit fields. The formulas differ, but
give the same results.
2. It would make describing floating point operations much harder. Every
statement of the form "In the remaining cases, where neither an
infinity, nor a zero, nor NaN is involved, and the operands have the
same sign or have different magnitudes, the exact mathematical sum is
computed." would need to be replaced by a more complicated discussion in
terms of the ranges of the two floating point numbers.
3. There are different rounding ranges for different purposes. An add is
allowed at most half a ulp of rounding error, and must round the half
way between numbers towards even. Math.sin is allowed one ulp of
rounding error. Which range does a double x represent? Only the add
results that would round to it? Or does x's range include sine(y) if
Math.sin(y)==x?
I find it simpler to go with the specs, and think of each floating point
number as having a unique value, surrounded a range of real numbers that
would be rounded to it under the arithmetic rounding rules, and broader
ranges that could be rounded to it under some of the more relaxed
function evaluation rules.
(b) you know the original precision of the binary floating point number.
Under those assumptions, which are quite reasonable for most uses, you
got back a correct answer with no loss of information versus the
original. However, if you don't assume (a), then the answer is
incorrect; and if you don't assume (b), then information was lost.
Hope that clarifies,
Certainly I find the normal Java Double.toString result very practical
for most, but not all, purposes. Printing the shortest decimal number
that Double.valueOf(String) would round to the double is a reasonable
default.
Patricia