== Quote from Sean Kelly (s...@invisibleduck.org)'s article > Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: > > On 2/21/11 6:08 PM, bearophile wrote: > >> Andrei Alexandrescu: > >> > >>> This is a long-standing myth. I worked on Wall Street and have friends > >>> who have been doing it for years. Everybody uses double. > >> > >> Unbrutal Python programmers are encouraged to avoid the float type to > >> manage money values, and use decimal instead: > >> http://docs.python.org/library/decimal.html > >> > >> Bye, > >> bearophile > > > > ... and nobody uses Python :o). > C/C++, Visual Basic, and SQL in my experience. Though in SQL they may use > the 'money' type. Using double really isn't an issue so long as rounding is > handled appropriately. It seems like a lot of the trouble stems from people > thinking values must be naturally exactly represented by the storage type.
The semantics of floating point are complicated, and I think the human brain usually sees 'complicated' and 'unpredictable/unstable' as synonyms. As for me, I heard long ago that double wasn't used and I think I believed it because I'd like to believe that someone out there is doing the responsible thing. Now that I have a bit more experience I can see that floating point is reliable, even if it is unintuitive. The instinct is to avoid it where correctness is important but if you analyze the code you can predict a lot about what floating point will do even if not always everything. If you can keep the error to the sub-penny level you should be fine with either approach. But I think C taught a lot of people to be wary. C considers an amazingly large percentage of its allowed syntax to have undefined semantics. Which direction integers round, sizes of basic types, bit shifting with values greater than sizeof(int)-1, etc. Almost anything that varies from CPU to CPU is not defined by C, with the result that you need to build a mini-jail in your mind to write portable code. Floating point is part of this because many floating point expressions produce different results depending on choices made by the compiler while optimizing, e.g. when to shift numbers from real <-> double. The number of things a language defines in a 'do whatever is easy or quick for your platform' ends up being a coefficient of the difficulty of using a language to write (portably) correct code. As a result, almost all large C programs are non-portable and I'm convinced the majority have undefined behavior if you take a narrow view of what C guarantees about the size of int, the order of side effects, and (if you really want to play hardball) the memory hierarchy in a multithreaded program. Kevin