Travis Scrimshaw wrote: >> Sorry, I don't understand your example: I think everyone agrees that >> ZZ == QQ should be False, but many people think that ZZ(1) == QQ(1) >> should be True (though I personally disagree), and my post only was >> about Elements. > > One potential side effect of what you're proposing is that ZZ == QQ > should raise an error.
No, my suggestion is strictly about Elements. (And if we'll have lots of deeper changes to make if we want objects that are both Parents and Elements!) >> > Subsequently, when there is no coercion between the parents, they >> > should not raise an error. >> >> Regarding ==, I believe it is a matter of convenience and >> consistency. Raising an error makes it easier to catch bugs, while >> returning False when there is no coercion allows things like [a for a >> in [1, "banana"] if a == 1]. > > It also makes it *significantly* harder to work with heterogeneous > data and really doesn't do too much to catch bugs. You end up with > more complicated code that has to often consider more cases. Suppose > ZZ(1) == QQ(1) raises an error. Then you have to manually do coercions > and make extra sure about your data types in a weakly typed language, > which is really hard from my experience. >From my POV, the two most consistent options would be: - either comparison operators that don't perform any coercions (except perhaps in an ad-hoc way between closely cooperating parents), respect Python semantics (wrt hash() & co), and return False for Elements that don't have the same parent, - or operators that are part of the coercion framework, and raise an error when they don't find a common parent. In the case of equality, I think it is pretty clear that both variants are useful and should exist in some form. The main question is which of the two should correspond to the Python comparison operators. Compatibility with Python collections and other non-Sage objects is a strong argument in favor of the former. Ease of use in interactive usage and backward compatibility are strong arguments in favor of the latter. That being said, I think it would be acceptable to special-case equality even if it does use coercion and make it return False when coercion fails. > If the coercion is not implemented, then I would say that is a bug > that would need to be fixed. In easy cases, yes, but in some cases it may very well correspond to an undecidable problem... > However, that is a good point about != > being not known to be == vs truly distinct. Although I would argue > that not known to be equal is an equivalent problem to knowing to be > distinct, and so the desire for an unknown result is good. Although it > should not be an error. Wait. To make sure we understand each other: I'm not saying that the error is here to indicate an unknown result. Since it is not possible to implement a reasonable three-valued logic for programming in Python, I think we should stick as much as possible to the convention that "True means true, False means false or unknown" (that already is the dominant one in Sage as far as I can tell), and that's why I'm saying that having == return False when it should actually fail is more acceptable that having != return True in the same situation. -- 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.
