`Order` for Numerics, e.g. `Order[1.0, 1] == -1` (but is 0)

[rocky]

Description

Mathics3 Order[] values for numerics do not take into account the type in numerics when values are the same.

How to Reproduce

In[1]= Order[1.0, 1]
Out[1]= -1  (* Correct value*)

Output Given

Out[1]= 0

Expected behavior

In Order, and Sort and element ordering when numeric values are equal, the element order is probably needed. We currently lump Numeric (PrecisionReal, MachineReal, Integer, Complex) together and I guess we shouldn't.

I tried adjusting this but I am seeing a problem where the test:

ColorNegate[Yellow] == Blue 

Fails because RGBColor[0, 0, 1.0] != RGBColor[0, 0, 1] and it should be ==. That possibly a separate bug, but it feels mixed in here, and I don't understand how to fix.

Priority Additional Context

I am wondering if this kind of thing is going to eventually factor into Boxing order. Is it?

Additional context

[mmatera]

This seems to happen because of the way we compare atoms by default (see mathics.core.atoms:74). When you compare a real with an integer, the equality operator for Reals (mathics.core.atoms:404) relies on that routine. We should handle the integer case (and rational too) in an special way, in this method.

[rocky]

This seems to happen because of the way we compare atoms by default (see mathics.core.atoms:74). When you compare a real with an integer, the equality operator for Reals (mathics.core.atoms:404) relies on that routine. We should handle the integer case (and rational too) in an special way, in this method.

I would have thought that a clean, regular and simple way would have been to add entries to mathics.core/keycomparable like:

BASIC_ATOM_COMPLEX_ELT_ORDER = 0x00  # Or whatever the correct ordering is
BASIC_ATOM_REAL_ELT_ORDER = 0x01
BASIC_ATOM_INTEGER_ELT_ORDER = 0x02
....

and I tried that. But then I run into the problem that RGBColor[1.0, 0, 0] != RGBColor[1, 0, 0] but they should be equal, and I don't see how to fix that.

[mmatera]

The problem is that there are different comparisons in different contexts:

• Expression-like comparison (1<1.), used for example in Sort[...]
• Pattern-like comparison, used in sorting rules (ej: Condition[A[x_],x>2] comes first than A[x_]).
• Arithmetic comparison (1==1.)
  The evaluation of == among numbers (and expressions including numbers) uses the arithmetic comparison, implemented at the level of __eq__, __neq__, __leq__,__geq__, etc

[rocky]

However, we do have a different sorting routine for compound element ordering, e.g., https://github.com/Mathics3/mathics-core/blob/master/mathics/core/expression.py#L1595, which also takes a parameter to indicate pattern precedence instead of element ordering.

If we need to add more specific sort functions or methods, let's do that. Or if the existing places need to be adjust to be more specific, let's do that.

(And that's why this bug was noted.)