Re: Floating-Point
Robert Craig wrote:
>1. floating-point calculations are not always exact, and a tiny
> error in a calculation can be magnified into a huge error.
> floor(0.99999) is 0, as is floor(0.9999999999... trillion places)
> It is your responsibility as a programmer to properly handle
> these situations.
>
>2. The number 0.1 and many others like it, can't be represented
> exactly in binary floating-point. You may get something like
> 0.09999999999999999 which leads to surprises when
> floor(10*x) is applied. The answer is not to seek out a
> binary f.p. software library that will give you trillions
> of digits of accuracy. That will just give you trillions of 9's.
> The answer is to apply a bit of rounding before you use floor(),
> or switch to Cobol. Even Cobol uses binary floating-point, but
> it also has something called "packed decimal" which has a few
> problems of its own.
Okay, but can we be assured that the floating point will always be less
than the decimal. Less than or equal will cause rounding problems, but
less than makes life reasonably easy.
>3. When you subtract numbers of approximately equal magnitude,
> you are likely to lose a lot of accuracy. Subtracting two numbers
> that are accurate to 16 digits can easily leave you with a result
> that is only accurate to 14, 13, ... whatever number of digits.
There appeared to be a break at the 15th place on an item that
was not a subtraction or other change. I still would like to know
where the 17th thru 20th digits in Irv's printout came from. Those
should be zero. If they are real, where did they come from? They
appear to be an artifact of the print conversion routine.
>4. All of the above applies to just about *any* programming
> language. It is a basic fact of life when binary floating-point
> is used. Intel and most other CPU's provide IEEE binary
> floating-point in the hardware.
True, as was noted earlier by me. That is why we need as much information
as possible. When the hardware is difficult at best, the only protection we
have is clear knowledge of the software.
>5. By default, Euphoria prints numbers rounded to 10
> significant digits. This is an arbitrary cutoff point that was
> chosen so as to not cause undue eyestrain or clutter.
> If you want to see more digits, use printf(1, "%.16e", x).
A note in the manual wouldn't hurt a thing. Guessing is hazardous
to the accuracy of calculations.
>6. Euphoria is not doing anything mysterious. It is using IEEE
> binary floating point for all floating-point calculations.
> Careful line by line study of the Euphoria source code
> would tell you nothing about these basic issues of
> floating-point accuracy. Recoding your calculation in C,
> or some other language will likely give you the same results.
Let's not be coy. Just because you don't wish to give it to us does not
mean that it wouldn't tell us something about the accuracy of calculations.
Better documentation would deflect a lot of these questions and requests.
Simple order of instructions in any particular calculation can have huge
effects on calculations where differences are small. The problem is that
small differences can arise in intermediate calculations that can lead
to totally spurious results. When one codes an equation, it is very
difficult to control the status of all those intermediate results without
very carefully breaking the equation into pieces and doing rounding at
specific points. Needless to say the effect of that on efficiency isn't
salutary either in the source or in the execution.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
