Nowhere does Sage ever claim that the operator == yields True iff the operands are "the same mathematical object". This is incompatible with the demands Python makes on how this operator behaves. Instead,== yields True if there is some structure into which both operands can be coerced, in which the results are equal. This does not mean that the original operands are in any normal sense equal.
A side-effect of this which has been much commented on here in the past is that the == operator is (therefore) *not* transitive. For example, sage: Mod(3,2)==1 True sage: 1==Mod(4,3) True sage: Mod(3,2)==Mod(4,3) False Now a mathematician would argue that the last one should raise some kind of error since we are apparently asking for the equality of objects in incomparable domains. But Python requires (I believe) that == should always return True or False, so that is not an option. John On 8 October 2013 19:22, Greg Laun <greg.l...@gmail.com> wrote: > > >> Sage's "in" is not a mathematical "\in", Sage's "RR" is not the field of >> real numbers. Peter is arguing to make them behave more like they are. >> Others are arguing not to change these things for various reasons. (And I >> will not get myself tangled up in that, since I don't know enough about >> floating point standards, nor do I know the reasons behind Sage's definition >> of "in".) >> > > As a user of Sage who is also trying to convert others to Sage, I would > advocate making the "in" keyword behave like "\in" and having RR and other > fields behave like their mathematical counterparts. As a matter of > programming, this can possibly be achieved by having the programer-friendly > implementation of RR etc be the primary implementations and then writing > user-friendly wrappers to these that behave intuitively. This could be > something like Peter is advocating with exceptions = True. > > My reading of this thread is that the problem extends beyond the infinity > ring, and that comparisons in general may not behave in an intuitive > mathematical way. For example: > sage: GF(2)(1) == 1 > True > sage: GF(2)(3) == 1 > True > > I see why these work on an implementation level, but this is strange: > > sage: A = matrix(GF(2), 2, [2,0,0,1]) > sage: B = matrix(2, [2,0,0,1]) > sage: A == B > True > sage: A.rank() > 1 > sage: B.rank() > 2 > > So we have a non-invertible matrix equal to an invertible matrix. I think > for most users, if two objects evaluate as equal, they should behave the > same under operations like * and +. This example breaks that assumption. > > Also strange: > > sage: C = matrix(GF(2), 2, [1, 0, 0, 1]) > sage: C in GL(2,RR) > True > > I think we'd benefit generally from thinking about use cases involving > novice Sage users and modifying the coercion framework (or whichever > component is involved here) to deal with these use cases. > > -Greg > > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
