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

Chris Barker chris.barker at noaa.gov
Tue Jan 13 02:18:45 CET 2015


OK,

I tossed together an example implementation:

https://gist.github.com/PythonCHB/6e9ef7732a9074d9337a

Simple enough, and seems to work fine for complex, too, out of the box
(just using plain old abs). I haven't tried it, but it should work for
integers (and decimal?), too, though less need for that anyway.

The Boost docs talk about overflow issues, but I can't trigger them, nor
see where there would show up, except for if the two values tested were
REALLY far apart, which isn't really the use case we're worried about. But
I could very well be missing something, I'm no FP expert.

It would probably be good if someone that understands these things better
than me came up with some near-pathological test cases.

Nathaniel, thanks for the pointer to the Boost docs -- I like this much
more than numpy's weird atol+rtol approach.

-Chris


On Mon, Jan 12, 2015 at 3:34 PM, Chris Barker <chris.barker at noaa.gov> wrote:

>
> On Mon, Jan 12, 2015 at 2:56 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> But should probably use complex abs().
>>
>
> maybe, it does add complication  -- I'd need to look more closely at the
> Boost code. And I'm trying to think if there are any numerical FP issues
> that would arise from that -- I'm no expert.
>
> Adding it to cmath makes sense (if adding it to math happens).
>>
>
> sure.
>
> And I hate to bring this up, but any reason for a cmath.nan and cmath.inf ?
>
>
> I wrote:
>
>> It looks like they start with two, but end up with
>> "the implementation is using modified version of the equations (1) and
>> (2) where all underflow, overflow conditions could be guarded safely"
>
>
> oops, they do indeed keep both versions, a "weak" and "strong" one.
>
> essentially, "is the error small enough relative to both input values, or
> only one of them. Fairly subtle difference, but I like the "strong"
> definition, as it gives the same result regardless of input order. though
> it does guarantee a bit of maybe unnecessary computation.
>
> I'm going to play with code a bit now.
>
> -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/20150112/7614ab0e/attachment-0001.html>


More information about the Python-ideas mailing list