[Python-ideas] PEP 485: A Function for testing approximate equality

[Paul Moore]

On 23 January 2015 at 17:21, Chris Barker <chris.barker at noaa.gov> wrote:
>> My worry is that what this
>> function will *actually* be used for is to allow naive users to gloss
>> over their lack of understanding of floating point:
>>
>>     n = 0.0
>>     while not is_close_to(n, 1.0): # Because I don't understand floating
>> point
>>         do_something_with(n)
>>         n += 0.1
>
> Is that necessarily worse? it would at least terminate ;-) floating point is
> a bit of an attractive nuisance anyway.

Than understanding what you're doing? Yes. But it's sort of my point
that fp is prone to people misunderstanding, and it's a shame to give
people more opportunities.

>> BTW, when writing that I had to keep scrolling up to see which order
>> actual and expected went in. I'd imagine plenty of naive users will
>> assume "it's symmetrical so it shouldn't matter" and get the order
>> wrong.
>
>
> Well, I think the biggest real issue about this (other than should it be in
> the stdlib at all) is the question of a symmetrical vs. symmetrical test. I
> decided to go (for this draft, anyway) with the asymmetric test, as it is
> better defined and easier to reason about, and more appropriate for some
> cases. And the biggest argument for a symmetric test is that it is what
> people would expect.
>
> So I tried to make the parameter names that would make it clear (rather than
> a,b or x,y) -- I think I failed on that, however -- anyone have a better
> suggestion for names? It turns out "actual" is far too similar in meaning to
> "expected".

Your parameter names and documentation are fine - it's very obvious
how to use the function when you look. It's just that you *need* to
look because an asymmetric check isn't immediately intuitive. I say
"immediately" because when I think about it yes, the question "is a
close enough to b?" is actually asymmetric.

>>  In summary - it looks too much like an attractive nuisance to me,
>
> If it's not there, the folks will cobble somethign up themselves (and I'm
> sure do, all the time). If they know what they are doing, and take care,
> then great, but if not then they may get something with worse behavior that
> this. Maybe they will at least understand it better, but I suspect the
> pitfalls will all still be there in a typical case. And in any case, have to
> take the time to write it. That's my logic anyway.

Yeah, you have a point. And TBH, I can ignore this function just as
easily as I currently ignore cmath.sin, so it's no big deal.

Guido's example of Newton iteration is a good use case (although most
of the time I'd expect to use a prebuilt function from a module,
rather than build it myself with Newton iteration, but maybe that just
reflects the fact that I don't do numerical programming).

Paul