| |||||||||||||
Careful with the omissions...Careful with the omissions...Posted May 1, 2006 23:59 UTC (Mon) by Stavros (guest, #36829)In reply to: a few notable omissions... by stevenj Parent article: Portability and Pitfalls of C-Types (developerWorks) [...] unless you really know what you are doing, use double precision! I disagree. In particular for storage, whether in memory or on disk, the careful choice of storage type for floats is a valuable memory jog telling you to pay attention to the precision of your calculations. An apparent loss of precision is rarely due to insufficient size of the storage or processing type but rather due to a poor choice of calculational method. The danger in simply taking the double-precision-short-cut is that you can fool yourself into thinking you have much more precision than you really do ("Look at all those digits!"). I have been working in scientific computing for many, many years and even there, where everyone should know better, it is surprising how often people calculate a small quantity by subtracting a large quantity from another large quantity and using double (or even quadruple) precision in the mistaken belief that the problem is solved. Then they are shocked when the input quantization wreaks havoc with the results. For those who want to know more, read "What Every Computer Scientist Should Know About Floating Point Arithmetic" (David Goldberg, 1991). The issues are also discussed in many books on numerical analysis, though often in less detail. Numerical calculaton is rarely simple and rules of thumb like using doubles by default can be very dangerous. Kudos if you know this and are careful in your math, but I worry about leading less aware people astray. -- Stavros
(Log in to post comments)
exponent range! Posted May 2, 2006 2:18 UTC (Tue) by jreiser (subscriber, #11027) [Link] The increased exponent range of double precision (about 10**308) in contrast to single precision (about 10**38) is at least as important as the increased precision (about 13 decimal digits vs. about 6.)
floating-point precision Posted May 2, 2006 7:36 UTC (Tue) by stevenj (guest, #421) [Link] You're absolutely right that these issues are tricky, and that double precision is not a panacea. However, Kahan's points are twofold: First, error analysis can be very nonobvious, and because of this it's dangerous to ask programmers to decide for themselves whether single precision is sufficient. As Kahan puts it, Except in extremely uncommon situations, extra-precise arithmetic generally attenuates risks due to roundoff at far less cost than the price of a competent error-analyst. Second, another misconception that Kahan warns about, which is quite common in my experience, is the myth that "Arithmetic should be barely more precise than the data and the desired result." Here, the developerWorks author suggested that the precision be determined by the "range you care about", which in my opinion is dangerously misleading at best—it could easily be read as saying that the precision is given by the desired accuracy of the result (or perhaps by the accuracy of the input, which is usually just as wrong), when in fact you have to worry about the intermediate calculations as well. For huge datasets, there is a strong incentive to use single precision, I agree. Even then it is often a good idea to perform in-cache intermediate calculations in double precision. I've read the Goldberg article, but I'm inclined to find Kahan's 80-page presentation (despite being a series of slides and not an article) to be more thought-provoking because it goes directly after common misconceptions and explodes them.
|
|||||||||||||