> The unary ~ (invert) operator yields the bitwise inversion of its integer argument. The bitwise inversion of x is defined as -(x+1). It only applies to integral numbers.
yes, the tilde would be good, but, well, is already a unary operator, not a binary one. And If we were to add a new operator, it should have the same precedence as == currently does, so we can't really re-use any others either.
But ~= would read well for those of us accustomed it its use in math.
Or, if ever Python goes to full on Unicode: ≈
> The above equation is not symmetric in a and b, so that allclose(a, b) might be different from allclose(b, a) in some rare cases.
There are a number of issues with the numpy implementations, one of which is this. We really wouldn't want an asymmetric equality-like operator. But that's one reason why math.isclose doesn't use that same algorithm: it is symmetric.
But that being said, I don't think this is a good idea, because of two issues:
1) as stated by Greg Ewing, if you are comparing floats, you really should be thinking about what tolerance makes sense in your use case.
2) Even more critical, isclose() has the absolute tolerance set to zero, so that nothing will compare as "close" to zero. So you can't really use it without thinking about what value makes sense in your use case.
Both of which lead to a basic concept: there is no single definition of"close", and operators can only have a single definition.
NOTE:
A way to get around that would be to have a global setting for the tolerances, or a context manager:
with close_tolerances(rel_tol=1e-12, abs_tol=1e-25):
if something ~= something_else:
do_something()
but frankly, the overhead of writing the extra code overwhelms that hassle of writing is_close().
So: -1 from me.
However, to Alex's point: if someone posts some motivating examples where the operator would really make the code more readable, *maybe* we could be persuaded.
-CHB