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

Nathaniel Smith njs at pobox.com
Tue Jan 13 03:32:15 CET 2015


Ok, but you're missing a huge issue, which is that according to the rule
you suggest, 0.0 is not close to any non-zero value. Handing such a
function to users and claiming it's the one "is close" predicate they need
is going to produce a lot of sad and confused users.

I don't want to step on your positive let's-fix-it attitude, I think that's
great, but... I do think you are really underestimating the complexity of
the problem.

The right way to handle comparison with zero, or comparison between epsilon
and negative epsilon, etc, really depends on the context. For common unit
test cases it may even make sense to prefer a non-symmetric predicate --
e.g. if you're expecting 0 then 1e-100 is usually fine, but if you're
expecting 1e-100 then getting 0 might be a huge problem.

-n
On 13 Jan 2015 01:19, "Chris Barker" <chris.barker at noaa.gov> wrote:

> 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
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150113/1d8d546b/attachment.html>


More information about the Python-ideas mailing list