bright@Data-IO.COM (Walter Bright) (10/11/88)
In article <8273@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: <In article <1706@dataio.Data-IO.COM<, bright@Data-IO.COM (Walter Bright) writes: << For example, suppose you wished to convert Celsius to Farenheit << in a tight loop. Multiplying by the scale factor is much faster << than dividing by the reciprocal, and the answer will be correct << to the desired accuracy. <This obviously depends on what you desire. For instance, <whether I evaluate < f = 32 + c * (9.0/5.0); <I will not get as accurate an answer as if I evaluate < f = 32 + (c * 9.0) / 5.0; <In particular, when <I convert 100 degrees Celsius to Fahrenheit, I get 212, not <211.9999999999999 or 212.0000000000001. The other two ways of <doing it do not guarantee that. Pulling out HP's "TEST AND MEASUREMENT CATALOG" for 1988, the most accurate thermometer they have is on page 345, the HP 2804A: to 0.040 C from -50 to 150 C to 0.075 C from -80 to 250 C Cost: $6000 16 digits of precision in the answer is simply irrelevant when your data is only good to 6 digits at best. Sorry. If you published a paper or turned in your lab report with temperatures with 16 digits written out, most good profs will give you an 'F' for trying to mislead the reader. That's why I picked this particular example. This is also a real world example in that I have a friend who once had to program a microprocessor to convert Farenheit to Celsius in real-time, and speed was simply more important than a 16 digit result. Before I get flamed: I know that there are many applications that stress the floating point accuracy to the limits, where max accuracy is required and speed is irrelevant. I'm merely pointing out that there is the other end of the spectrum also.