Fix equality

[stephenworsley]

This pull request currently shows an approach to solving #3529 which, while failed, I think is still instructive.

I tried comparing _ancillary_variables_and_dims and _cell_measures_and_dims in a way which would ignore their order as lists. This first attempt involved simply turning these lists into sets. This failed because the objects inside the lists are not viable elements of a set.

One idea I am coming around to, if such a comparison is deemed necessary, is to use the code in this function:

iris/lib/iris/analysis/__init__.py

Line 189 in a054241

def coord_comparison(*cubes):

perhaps creating a generic version which compares generic aspects of a cube, then having coord_comparison and something like ancil_comparison wrap this generic function. I'm leaning towards this idea since it seems as though coord_comparison is designed to be more efficient than a more naive, brute force approach. If we needed to compare many ancillary variables (which seems like a thing we would probably want to do) it seems likely we would end up writing something similar to what already exists in this code anyway.

[stephenworsley]

After having a bit more of a look at coord_comparison, this may not be the most efficient way to determine equality either, since dimensions within the cube are checked for equality after the data in the coords are checked for equality. There's still a case to make a generic function that checks equality of various *_and dims properties.

[pp-mo]

This first attempt involved simply turning these lists into sets. This failed because the objects inside the lists are not viable elements of a set.

I think you've mis-diagnosed what was wrong here.

The errors with set creation occur because the elements of cube._ancillary_variables_and_dims are of the form [ancil-var-object, dims-tuple].
I think that is just a mistake. The entries in that list should be 2-tuples (var, dims), not lists.
So the problem is just this line, which I reckon should be making a 2-tuple instead of a 2-element list.

And the same thing needs fixing for cell measures here.
( I suspect this is yet another case where the cell-measures implementation was slightly wrong, we never noticed, we copied it, and now we are having trouble ! ... )

If you fix those, I think the set approach will work.
It seems to be mostly working when I try it (modulo a few more unrelated problems?)
See: #3537

I really like this approach (if you can make it work), because it provides all the needed logic based only+entirely on equality testing, which being a standard approach is very easy to understand.

[pp-mo]

WARNING
@bjlittle / @rhattersley pointed out that the ordering of cell-methods is significant.
#3530
So in that case we can have simple list equality.

[stephenworsley]

@pp-mo For consistency, I have made the same change to dim_coords_and_dims and aux_coords_and_dims. Also, I have added a test to make sure reordering cell methods causes equality to fail.

[pp-mo]

Should we have a successful comparison with cell-methods here, or is that covered somewhere else ?

[stephenworsley]

This is capturing the behaviour mentioned in the comments on #3530. Adding cell_methods in different orders should cause equality to fail.

[pp-mo]

Misunderstanding I think !
What I meant to say was : do we need another testcase showing that equality testing succeeds, when the cubes have cell methods, but they do match.
( Unless that is clearly covered somewhere else ?? )

[stephenworsley]

ah, yeah, that sounds appropriate.

[pp-mo]

Looking very close, I think I'd still push for a test of successful cell-method comparisons, OWOK ! 😁

[pp-mo]

Good stuff 👍

[stephenworsley]

Closes #3529.