Thank you for you comments.
Kwankyu Lee wrote:
> (1) "x != y" should behave always and exactly as "not (x == y)"
This is difficult to achieve.
For example, in interval arithmetic, one usually expects a == b to
return True iff a and b are equal point intervals, and a != b to return
True iff a and b are disjoint intervals. Also, for lots of objects
coming up in computer algebra (e.g., symbolic expressions in one
variable), the equality test is either undecidable or at least not known
to be decidable.
In all these cases, there are at least three possible outcomes for the
comparison a == b:
- a and b can be determined to be equal,
- a and b can be determined to be different,
- a and b are neither known to be equal nor known to be different
(and perhaps, sometimes, variants like "a and b are known to be
neither equal nor different": e.g., the IEEE standard for floating-
point arithmetic says that NaN == NaN and NaN != NaN should both
return False, and it is not clear that this can be considered a case
where the "actual" result is unknown, as with interval arithmetic).
Then, the questions "are a and b known to be equal" and "are a and b
known to be different" are not the same. For example, if you are trying
to make sure that a matrix is nonsingular, you will usually want to test
that its determinant is known to be nonzero. If, however, you are trying
to decide whether a term can be dropped from the representation of a
polynomial, you'll usually want to test if it is known to be zero.
A partial solution to these problems is to allow comparisons to return
"Unknown" instead of just "True" or "False". This is in fact possible;
however (as discussed at length on sage-devel in the past), Python will
need to convert the "Unknown" result to a boolean as soon as it is used
as part of a conditional expression, so that we essentially are back to
the previous problem.
(I guess one could implement a more explicit, if essentially equivalent,
way of handling that, e.g. have comparisons themselves return Unknown,
conversions from Unknown objects to boolean raise an exception, and
introduce "modality" operators for the various possible conversions from
{True,False,Unknown} to {True,False}. But that's not how things are done
in Sage for now.)
> (2) When parents of x and y are different after coercion, "x != y" ("x
> == y") returns True (False) for both (i) and (ii)
Why only "after coercion"? I would understand that x != y return False
as soon as x and y have different parents--that would actually be the
best convention from my POV, but many people disagree, and that would be
a major break of compatibility. But I don't like the idea that a
comparison that makes sense mathematically returns True or False
depending whether the coercion system finds a common parent or not.
Besides, it is not hard to find cases where the user could *expect* the
system to make sense of the comparison, even though x and y actually
have good reasons not to have a common parent.
In other words: the choice has been made, long ago, to have ==/!= in
Sage stand for "semantic" comparison of mathematical objects rather than
"syntactic" comparison of data structures. I don't think it was the
right choice, but as long as we stick to it, it seems to me that
comparisons that don't have a well-defined mathematical result should
fail whenever practical, and return False (under the above asymmetric
interpretation) if they really need to return a boolean result.
> (3) "x != y" and "x == y" never raise an exception.
Why? We are not talking about raising exceptions all the time, only in
cases where it is likely that there is a bug...
--
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.
