[Python-ideas] Floating point "closeness" Proposal Outline
Chris Barker - NOAA Federal
chris.barker at noaa.gov
Wed Jan 21 17:07:10 CET 2015
> It just hit me that while this intransivity is strange, mathematically
> speaking, it
> _is_ indeed what happens in "the real world" when we are dealing with
> - this wood piece example being more than enough to show it.
The wood piece example is analogous to accumulated floating point
error. A good carpenter knows not to do that, just as a good
programmer knows not to successively add 0.1 floats and expect to get
a nice round result.
But measurement of error is a key issue here. For the use cases Ron
brings up, that is, answering the question " is this measured value
within some relative tolerance of another, known, and presumed to be
exact, value?" Then yes, the asymmetric approach, where you specify
which value is the "known" one, is the way to do it.
But is that the use-case that's likely to be common? I think there are
a heck of a lot of people that need to check if two values are close
to each other for tests and whatnot, than writing python code for a
quality assurance system.
So what do we need for the common use case? It may not be that
different, actually. You probably do often have a computed value that
you are checking against a known result. In which case the asymmetric
approach is clear and makes sense.
Again, for what I think is the MOST common case: " I just want to know
if I'm in the ballpark" it doesn't matter which is used.
But we should probably call it "is_close_to" or some such, and name
the parameters clearly.
More information about the Python-ideas