Re: Floating-Point
- Posted by Everett Williams <rett at GVTC.COM> Mar 20, 2000
- 442 views
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