Travis Scrimshaw wrote:
> We need to be very careful about defining "not knowing". I (stongly)
> believe when the objects/types are incomparable (say the rings ZZ and
> QQ), then == should return False and != should return True.
> Subsequently, when there is no coercion between the parents, they
> should not raise an error.
Does anyone else have comments on this issue? Specifically, what should
x != y do in your opinion when
- x is a Sage Element,
- y is
(i) another Element, or
(ii) a non-Element that does not implement rich comparison
with Elements,
- and the coercion framework finds no common parent for x and y?
The main options are to:
(a) return True,
(b) raise a TypeError.
Note that this is not equivalent to asking what == should do in a
similar situation.
I guess the main argument in favor of (a) is that it makes it possible
to say things like
if x != "foo":
x.frobnicate()
more or less whatever x is. Forbidding it may lead to problems in
existing external code, and the alternative version
if not (x == "foo"):
x.frobnicate()
(which would still work) is uglier and counter-intuitive.
The main argument I see for (b) is consistency with how coercion works
in general. When y is a string as above, or even when y is an Element
that has nothing to do with x, choosing (b) over (a) might help catch
some bugs, but I don't think there is much that can go wrong with (a).
The situation is more complicated when there is a common parent where
the comparison could be performed but the coercion framework is not
powerful enough to find it, like
sage: K.<sqrt2> = QQ[sqrt(2)]
sage: sqrt2 != QQbar(sqrt(2)) # mathematically wrong result!
True
or when the user (being used to Sage trying to make sense of comparisons
between elements of different parents) could mistake the output for more
than what it is, e.g.,
sage: QQ['x'].one() != QQ['y'].one()
True
sage: QQ['x'].one() != GF(2).one() # False with ZZ['x']
True
sage: RLF(pi) != pi
True
sage: RIF(-1, 1) != RBF(0) # are [-1,1] and {0} disjoint?
True
Incidentally, forcing people to change x != y to not(x == y) in some
cases may not be such a bad thing. Indeed, the two are not always
equivalent (the archetypal examples being intervals and domains where
equality is mathematically well-defined but undecidable), and situations
where option (b) would make x != y fail often are cases where the
programmer actually means not(x == y).
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
