float equality

Kevin Bealer kevindangerbealer at removedanger.gmail.com
Wed Feb 23 19:41:50 PST 2011


== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> Andrei Alexandrescu <SeeWebsiteForEmail at 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


More information about the Digitalmars-d mailing list