[Python-ideas] Floating point "closeness" Proposal Outline

[Ron Adam]

On 01/19/2015 12:32 AM, Chris Barker wrote:
>
> Here is a gist with a sample implementation:
>
> https://gist.github.com/PythonCHB/6e9ef7732a9074d9337a

For the most part I think it looks good.

Boost describes both a week and strong version, but I didn't see why they 
choose the strong version.  I'm guessing that "strong" indicates it has a 
higher certainty that the numbers are within the specified tolerance.

By using "and", it excludes the case when one is in the range and the other 
is not.  I think this needs to be in the description.


Your function can test for absolute distance, relative distance, or the 
greater of both.  You could have the defaults for both be zero, and raise 
an error if at least one isn't set to something other than zero.


> I need to add more tests, and make the test proper unit tests, but it's a
> start.
>
> I also need to see how it does with other data types than float --
> hopefully, it will "just work" with the core set.
>
> I hope we can come to some consensus that something like this is the way to go.

Good examples will help with this.  It may also help with choosing a good name.



To me, the strong version is an "is-good" test, and the weak version is an 
"is-close" test.  I think it could be important to some people.

I like the idea of being able to use these as a teaching tool to 
demonstrate how our ideas of closeness, equality, and inequality can be 
subjective.


There are two cases...

1: (The weak version is require for this to work.)

Two number are definitely equivalent if they are the same.  (pretty obvious)

Two numbers are definitely not equivalent if they are further apart than 
the largest error amount.  (The larger number better indicates the 
largeness of the the possible relative error.)

And two numbers are close if you can't determine if they are equivalent, or 
not-equivalent with certainty.*

(* "close numbers" may include equivalent numbers if you define it as a set 
of all definitely not-equivalent numbers.)



2: (The strong version is required for this to work.)

A value is good if it's within a valid range with certainty.  It is less 
than the smaller relative range of either number.  The smaller number 
better indicates the magnitude of smallness.



So case 1 should be used to test for errors, and case 2 should be used to 
test for valid ranges.

It seems you have the 2nd case in mind, and that's fine.  Some of us where 
thinking of the first case, and possibly switching from one to the other 
during the discussion which is probably why it got confusing or repetitious 
at some points.


I think both of these are useful, but you definitely need to be clear which 
one you are implementing, and to document it clearly.

Cheers,
    Ron