Comparing integer-ish types should maybe use operator.index

[oscarbenjamin]

This comes from a SymPy issue: sympy/sympy#26791

Flint's nmod does not compare equal to SymPy's Integer type in the same way that ints do:

In [22]: flint.nmod(3, 5) == 3
Out[22]: True

In [23]: flint.nmod(3, 5) == -2
Out[23]: True

In [24]: flint.nmod(3, 5) == sympy.Integer(3)
Out[24]: True

In [25]: flint.nmod(3, 5) == sympy.Integer(-2)
Out[25]: False

This happens because sympy's Integer.__eq__ will coerce the nmod to an integer. I have proposed to remove that behaviour in sympy/sympy#26795. With that change we would instead have:

In [3]: flint.nmod(3, 5) == sympy.Integer(3)
Out[3]: False

In [4]: flint.nmod(3, 5) == sympy.Integer(-2)
Out[4]: False

This is at least consistent in the sense that unequal types might be expected to compare as unequal. What happens here is just that both types return NotImplemented and so the default for == is False.

I wonder though if it would be better for flint.nmod to check for __index__ (using operator.index) when checking for equality so that it could compare equal to other "integer-like" types like np.int64 etc. Then both of the above cases would return True and would behave the same for int or Integer or any other integer-like types.

It is not clear in general how positive characteristic rings should behave in Python because they don't fit anywhere in the numeric scheme. In some ways it would seem cleaner to say that nmod should never compare equal to an integer but maybe that just makes them awkward to use. That is how the behaviour currently works for other positive characteristic types though:

In [2]: flint.nmod_poly([1, 2, 1], 3) == flint.fmpz_poly([1, 2, 1])
Out[2]: False

In [3]: flint.fmpq_poly([1, 2, 1]) == flint.fmpz_poly([1, 2, 1])
Out[3]: True

In [6]: flint.nmod_mat([[1]], 3) == flint.fmpz_mat([[1]])
Out[6]: False

In [7]: flint.fmpq_mat([[1]]) == flint.fmpz_mat([[1]])
Out[7]: True