Configurable numeric equality

[trexfeathers]

From offline discussion between @trexfeathers, @bjlittle, @pp-mo

Just as with metadata equality, Iris users have diverse needs when it comes to numeric equality¹:

• Precise equality? Example
• Allow for floating point differences? Example
  • If so, how much relative/absolute tolerance? See np.allclose()
• How should NaN be handled? Example

These considerations touch all corners of Iris: arithmetic, merging (and therefore loading), constraints (I remember #4744), and many more. Not only is this about whether numbers are equal, but also performance (e.g. #5926).

Problems

• Iris is inconsistent on the type of equality, depending on the operation
• Iris is often opaque about which type of equality is used where
• It is rare for a user to have control over the type of equality used, since it is often used in internal decision making (Can this Cube be subtracted from that Cube? Are these Coords duplicates? Etcetera)

Suggestion

Given different user needs, it would probably be unwise to enforce a consistent approach everywhere. User configuration seems the better approach, but since this is often about Iris internals I personally favour a global config with a context manager. We have established a precedent with Leniency, although this would not look exactly the same since it seems overly complex to offer the config as a parameter for every affected operation.

Possible settings

Allow the user to set any of the kwargs in np.allclose(). Perhaps if nothing is set then exact equality is used - possibly using a fast hashing algorithm.

Footnotes

1. I am mostly referring to arrays, but this may apply to single numbers such as those in a CoordSystem subclass. ↩

[trexfeathers]

Ping @larsbarring

[larsbarring]

Thanks for picking this up! I like the general idea of first using fast hashing (allowing for NaNs) -- after all we expect datasets to be well-behaved and usually they are. But if not, then do something more lenient (an possibly more time-consuming). BTW, as you write that this touches all corners of Iris, is it still confined "only" to coordinates and CoordSystem data (it is as far as we have seen)?

[trexfeathers]

I mean that equality in general touches all corners of Iris, and there is a lot of inconsistency when it comes to NaNs and floating point tolerance.