Z/nZ elements behave weirdly with integers

[lgoettgens]

julia> ZZn = residue_ring(ZZ,17)
Integers module 17

julia> 5 == ZZn(5)
true

julia> [5] == [ZZn(5)]
true

julia> Set([5]) == Set([ZZn(5)])
false

I find it very confusing that the behavior differs between vectors and sets.

This is probably due to their hashes being different.

julia> hash(5)
0xcaf5148d95ea2900

julia> hash(ZZn(5))
0xd2e7beb90721ddd9

This behavior contradicts the julia requirement for hash.

Compute an integer hash code such that isequal(x,y) implies hash(x)==hash(y).
(see docstring of hash)

But as 5 == ZZn(5) == 22, by transitivity of hash equality, hash(5) == hash(22) would have to hold, what we do not want and cannot change.

As the only wait out of this, I would propose to remove ==(::ZZElem, ::zModRingElem) and similar.

[thofma]

I don't think that the mismatch between array and set comparison is a big problem. Julia itself has this "problem":

julia> [missing] == [missing]
missing

julia> Set([missing]) == Set([missing])
true

julia> [0/-1] == [0/1]
true

julia> Set([0/-1]) == Set([0/1])
false

Removing the == methods would mean removing also QQ(1) == 1 and many other methods, which we don't want. I believe that disallowing the coercion would be more confusing.

EDIT: We could implement isequal for our types to make it not contradict the julia requirement for hash, but is it worth it?

[fingolfin]

Personally I always disliked that we allow things like 5 == ZZn(5) -- it is convenient in limited cases but overall seems like a potential source of bugs? In reality, the only comparisons I see in the wild are x == 0 and x == 1 and for these we already have iszero and isone...

But truth is, people use this, people want this, people are confused if they can't do it ....

And in any case, we can't just drop these comparisons, as that would break too much code, and it is difficult to find that code. If we were to remove these (and I doubt we could find a consensus on this at this point), then we'd have to install a method that made things like 5 == ZZn(5) throw an error (instead of returning false, as would be the "normal" thing in Julia). Both to find (and adjust) existing code relying on the current behavior, and to catch user mistakes trying to do 5 == ZZn(5)