Re: Floating-Point
- Posted by Everett Williams <rett at GVTC.COM> Mar 20, 2000
- 444 views
Robert Craig wrote: >Everett Williams writes: > >> Okay, but can we be assured that the floating point will >> always be less than the decimal. > >No, you shouldn't assume that. > >It's really not as bad as it sounds. >Just keep in mind that floating-point numbers are >an approximation to the real numbers. Ask yourself >"what if the result is a tiny bit higher or lower than >mathematics says it should be? Will my code still work?" Having tracked down a problem relating to the change in float rounding from COBOL F to COBOL G, I can testify that small, but inconsistent differences can become huge over time. The case in point was a joint and reducing term life insurance calculation for mortgages. A change in the rounding technique in the last position did cause anywhere from no change to as much as 25% off, a matter of thousands of dollars. Any repetitive use of of a small error without forced rounding( and that would be very difficult in some of those calculations) can either cancel or swiftly take the calculation completely off course. The problem is anything but trivial and it effects a fairly broad set of problems. On the IBM, only calculations that absolutely required the float used it, because packed decimal was available and was completely dependable, though limited in scope and slow. snip >The print conversion routine does its best to convert >from binary f.p. to a decimal representation. There is >no reason why 0's should suddenly appear after >16 decimal digits. It's true that the digits after >about 16 are pretty much random noise and should >not be taken too seriously. It's pointless to print more >than about 16 digits, given the current use of 64-bit f.p. The routine should truncate or round at the last possibly significant digit...the 16th according to the manual. At the very least the manual should be corrected and an addendum be added with some of the effects noted. Not everybody has or will have experience with other languages where this is documented more thoroughly. Everett L.(Rett) Williams rett at gvtc.com