On 2012-02-03 11:35:39 -0500, Robert Dewar wrote:
> On 2/3/2012 10:55 AM, Vincent Lefevre wrote:
> >On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
> >>What is the basis for that claim? to me it seems useless to expect
> >>anything from such absurd arguments. Can you site a requirement to
> >>the contrary (other than your (to me) unrealistic expectations).
> >>In particular, such large numbers are of course represented
^^^^^^^^^^^^^^^^^^
> >>imprecisely.
> >
> >Actually you don't know.
>
> Yes, I do! The floating-point representation of this number
Well, there is a difference between large numbers in general (which
may or may not be represented exactly, depending on the value) and
the example given by Konstantin.
> does NOT represent the number you wrote, but a slightly different
> number,
This fact is not even necessarily correct because you don't know the
intent of the programmer. In the program,
double a = 4.47460300787e+182;
could mean two things:
1. A number which approximates the decimal number 4.47460300787e+182,
in which case I agree with you. Note that even though it is an
approximation, the approximated value a is the same on two different
IEEE 754 platforms, so that one can expect that sin(a) gives two
values that are close to each other on these two different platforms.
2. A number exactly equal to the rounding (to nearest) of the decimal
number 4.47460300787e+182 in double precision. Imagine that you have
a binary64 (double precision) number, convert it to decimal with
sufficient precision in order to be able to convert it back to the
original binary64 number. This decimal string could have been the
result of such a conversion. IEEE 754 has been designed to be able
to do that. This choice has also been followed by some XML spec on
schemas, i.e. if you write 4.47460300787e+182, this really means a
binary64 number, not the decimal number 4.47460300787e+182 (even
though an hex format would be less ambiguous without context, the
decimal format also allows the human to have an idea about the
number).
> whose cos/sin values will be wildly
> different from the cos/sin values of the number you wrote,
> so what's the point of trying to get that value exact, when
> it is not the value you are looking for anyway.
>
> >Of course, the value probably comes from
> >somewhere, where it is imprecise. But there are codes that assume
> >that their input values should be regarded as exact or they will
> >no longer work. Reasons can be that algorithms are designed in such
> >a way and/or that consistency is important. A particular field is
> >computational geometry. For instance, you have a point and a line
> >given by their coordinates, which are in general imprecise.
> >Nevertheless, one generally wants to consider that the point is
> >always seen as being on one fixed side of the line (or exactly on
> >the line). If some parts of the program, because they do not compute
> >with high precision enough, behave as if the point were on some side
> >and other parts behave as if the point were on the other side, this
> >can yield important problems.
>
> But if you write arbitrary floating-point constants, then of
> course they are not represented exactly in general.
In general, but not always. And even if the initial constants do not
represent exactly the real values, one may want them to be handled
in a consistent manner (as if they were exact).
> >Another property that one may want is "correct rounding", mainly
> >for reproducibility. For instance, this was needed by the LHC@home
> >project of CERN (to check results performed on different machines,
> >IIRC), even though the results were complete chaos.
>
> Well of course you will get different results for this on different
> machines, regardless of "correct rounding", whatever that means!
No, thanks to correct rounding (provided by CRlibm), all machines with
the same inputs were giving the same results, even though the results
were meaningless.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
