Cannot compare equality of two ApproxSequencelike objects

[benjaminhwilliams]

Question summary

I notice a slight incongruity between the behaviour of ApproxScalar and that of ApproxSequencelike. Is this by design, or by accident?

Happy to help

If a change in the behaviour of ApproxSequencelike is something that people would like to see, I'm happy to have a go at a PR.

Details

Ordinarily, one would only need to have one member of an equality comparison be treated with pytest.approx, like so:

>>> 1 == pytest.approx(1)
True

But, in fact, you can treat both members of an equality comparison with pytest.approx, if the comparison is between scalars:

>>> pytest.approx(1) == pytest.approx(1)
True

By comparison, and rather incongruously, ApproxSequencelike doesn't share the friendly behaviour of ApproxScalar.

>>> [1] == pytest.approx([1])
True
>>> pytest.approx([1]) == pytest.approx([1])
False

Why care?

One wouldn't normally need to bother about this, but I stumbled on it when trying to apply pytest.approx to some chained comparisons. Consider this trivial example:

>>> [np.arcsin(np.sin(1))] == [np.arccos(np.cos(1))] == [1]
False
>>> [np.arcsin(np.sin(1))] == pytest.approx([np.arccos(np.cos(1))]) == pytest.approx([1])
False

A workaround is to apply pytest.approx only to every other value in the chain of comparisons:

>>> [np.arcsin(np.sin(1))] == pytest.approx([np.arccos(np.cos(1))]) == [1]
True
>>> pytest.approx([np.arcsin(np.sin(1))]) == [np.arccos(np.cos(1))] == pytest.approx([1])
True

But that feels a bit quirky, and I can't find it documented anywhere for new users of pytest.approx.

[kalekundert]

approx() is meant to be thought of as the reference value in a comparison, so I don't think it really makes sense to compare two approx instances to each other. For example, it's not clear whether the following should be True or False:

# The left operand is approximately close to 11, but the 
# right operand is not approximately close to 10...
approx(10, abs=2) == approx(11, abs=0.2)

If you actually try making this comparison, you'll find that the result depends on the order of the operands:

>>> approx(10, abs=2) == approx(11, abs=0.2)
False
>>> approx(11, abs=0.2) == approx(10, abs=2)
True

My opinion is that comparisons like this should probably be errors. Even if they aren't (yet), I would avoid them. Instead, I would write the example you gave as follows:

assert [np.arcsin(np.sin(1))] == pytest.approx([1])
assert [np.arccos(np.cos(1))] == pytest.approx([1])

[benjaminhwilliams]

OK, thanks, that makes sense. I can see that the desired behaviour when comparing two pytest.approx calls is not clear, whereas using it purely to provide a reference value is clear. I'm happy just to always split up chained comparisons when dealing with pytest.approx.