Perhaps a more versatile operator would be to introduce a +- operator that
would return an object with an __eq__ method that checks for equality in
the tolerance i.e
a == b +- 0.5
Although I don't like this either since you could achieve the same thing
with something like this:
class Tolerance:
def __init__(self, upper, lower=None):
self.upper = upper
self.lower = upper if lower is None else lower
def __add__(self, number):
return Tolerance(number+self.upper, number-self.lower)
def __sub__(self, number):
return Tolerance(number-self.upper, number+self.lower)
def __eq__(self, number):
return self.lower < number < self.upper
a == b + Tolerance(0.5)
So maybe it would be nice to have something like this built into math?
On Thu, 18 Jun 2020 at 17:56, Steven D'Aprano <st...@pearwood.info> wrote:
> On Sun, Jun 14, 2020 at 02:39:49PM +0200, Sebastian M. Ernst wrote:
> > Hi all,
> >
> > after just having typed tons of `math.isclose` (see PEP 485 [1]) and
> > `numpy.isclose` calls (while basically using their default tolerances
> > most of the time), I was wondering whether it makes sense to add a
> > matching operator.
>
> I wrote the statistics module in the stdlib, and the tests for that use
> a lot of approximate equality tests:
>
> https://github.com/python/cpython/blob/3.8/Lib/test/test_statistics.py
>
> which includes an approx_equal function that pre-dates the math.isclose
> and a unittest assertApproxEqual method. So I like to think I'm a heavy
> user of approximate comparisons.
>
> I wouldn't use an approximate operator. Not even if it were written with
> the unicode ≈ ALMOST EQUAL TO symbol :-)
>
> The problem is that the operator can only have a single pre-defined
> tolerance (or a pair of tolerances, absolute and relative), which
> would not be very useful in practice. So I would have to swap from the
> operator to a function call, and it is highly unlikely that the operator
> tolerances would be what I need the majority of the time.
>
>
> --
> Steven
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6AWLMPZCLZCUG6BUBV6JF5XHUQYQAYC5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Notice:
This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this message
may not necessarily reflect the opinions and views of the members of the
Ocado Group.
If you are not the intended recipient, please notify us
immediately and delete all copies of this message. Please note that it is
your responsibility to scan this message for viruses.
References to the
"Ocado Group" are to Ocado Group plc (registered in England and Wales with
number 7098618) and its subsidiary undertakings (as that expression is
defined in the Companies Act 2006) from time to time. The registered office
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way,
Hatfield, Hertfordshire, AL10 9UL.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KTBKOWCSPUUX63PMRO57Z2T6KLPMJGO5/
Code of Conduct: http://python.org/psf/codeofconduct/
