I think, that is a good example to explain how I understand â€ścanonicalâ€ť. Order relations are mathematical objects, which and they interrelate with other mathematical objects, like additive structures. There is a theory behind that, which works like a mobile in equilibrium - if you change one little part, it gets in motion and a lot of things do not work any more. That is why I am reluctant to extend the domain of certain functions, which handle mathematical objects to types, which do not behave â€śmathematicallyâ€ť.

Let me come back to the original subject: how and if should `isless`

and `cmp`

be defined for `AbstractArray`

?

I would recommend, to keep the following contract valid:

For each a and b of the same type, which is in the domain of isless/cmp (Ă¬sless(::T,::T) where T) exactly one of the following statements shall be true

Either `isless(a,b) === true`

or `isless(b,a) === true`

or `isequal(a, b) === true`

.

Also `cmp(a,b) < 0 <=> isless(a,b)`

and `cmp(a,b) > 0 <=> isless(b,a)`

and `cmp(a,b) == 0 <=> isequal(a,b)`

.

Besides that, of course associatitvity, antisymmetry, reflectivity has to be respected.

This contract can be followed by a lexicographical order for arrays, if you make the following restrictions:

- Arrays of different shape cannot be compared (throw exception).
- the elements are iterated in a defined fashion, which must be clear to the user, and compared element-wise until the first difference is detected.
- The element type must follow the above contract about isless/cmp.

It is an open decision, if we restrict that to one-dimensional arrays (only one of the `size(a)`

elements is different form `1`

).

For `Tuple`

, the decision to use lexicographical ordering has been made long ago and is ok. Tuples are in my reception less â€śmathematicalâ€ť than arrays and vectors and serve different purposes.

For complex numbers, ordering would be surprising and on purpose. If there is a reason to present or process a set of complex numbers in a certain order, there are probably as many different orders as there are application uses. For example I once sorted eigenvalues first by abs of the real part, then by the negative of the imaginary part - and that was appropriate for my use case.

I would prefer to not provide a standard ordering, but delegate that to the user. Reason