[Python-ideas] Fwd: Way to check for floating point "closeness"?

[Chris Barker]

oops, forgot ot reply-all

---------- Forwarded message ----------
From: Chris Barker <chris.barker at noaa.gov>
Date: Sat, Jan 17, 2015 at 8:38 PM
Subject: Re: [Python-ideas] Way to check for floating point "closeness"?
To: Terry Reedy <tjreedy at udel.edu>


On Fri, Jan 16, 2015 at 8:09 PM, Terry Reedy <tjreedy at udel.edu> wrote:


> As near as I can tell,
> assertAlmostEqual(first, second, places=7, msg=None, delta=None)
> does one of two possible absolute difference checks
> (round(first, places) - round(second, places)) == 0.0
> abs(first - second) < = delta
>
> There has been discussion of making it more complicated, but I remember
> that being rejected because other tests require more thought and can be
> implemented with the above anyway.
>

anything could be implemented with a simple absolute tolerance method, and
for that matter, that is simple enough that there's not much point in
having a built in function for it.anted (and a bit harder to write yourself)

>
> assertAlmostEqual((a-b)/d, 0, delta = tol)
> where d is a, b, and (a+b)/2 as one thinks is appropriate.
>

while yopu're at it, why not jsut write your own assertion:

assert (a-b)/b <= tol

that function buys you nothing but potential confusion.


> The discussion on the thread seems mostly divorced from the multiple use
> cases.  What do each of a and b represent? Different numbers?  or
> successive approximations of the same number?  Are they theoretical 'exact'
> numbers, approximations of theoretical numbers, or calculations from
> measurements with error?  If the latter, how big is the error?  And why are
> we asking anyway?  We are usually asking 'close enough' for some purpose,
> but purposes differ.
>

yes, they sure do -- but anything in the standard library would be for
general use, where the details don't matter too much -- if you are doing
something really specific, write your own test.


>   (Someone claimed that 'nothing is close to zero'.  This is nonsensical
> both in applied math and everyday life.)


I'm pretty sure someone (more than one of use) asserted that "nothing is
*relatively* close to zero -- very different.

And indeed, that is still a primary stumbling block (at least for me) to
putting a relative tolerance function into the stdlib: it will work fine in
most cases, and be easy to understand and reason about, but it will not
work if one of the input values is zero, and casual users may get tripped
up by that. But at this point, i think that just needs  note in the docs --
after all, they are likely to get tripped up by that if they write the code
themselves anyway.

And I really wanted a way to have a default behavior that would do a
reasonable transition to an absolute tolerance near zero, but I no longer
thing that's possible. (numpy's implimentaion kind of does that, but it is
really wrong for small numbers, and if you made the default min_tolerance
the smallest possible representable number, it really wouldn't be useful.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150117/d646510d/attachment.html>