On 21 February 2010 16:05, Minh Nguyen <nguyenmi...@gmail.com> wrote: > On Mon, Feb 22, 2010 at 3:01 AM, slabbe <sla...@gmail.com> wrote: > > <SNIP> > >> sage: 15.mod(4) == 7 >> False >> sage: mod(15, 4) == 7 >> True > > Is the following the intended behaviour? > > sage: type(15.mod(4)) > <type 'sage.rings.integer.Integer'> > sage: type(mod(15, 4).lift()) > <type 'sage.rings.integer.Integer'> > sage: 15.mod(4) == 7 > False > sage: mod(15, 4).lift() == 7 > False >
This is entirely consistent, though possibly unexpected. Both a.mod(n) and a%n return an integer which is "a reduced modulo n", while mod(a,n) returns an element of Z/nZ. Now the only surprising thing, perhaps, is the test that mod(15, 4) == 7 which yields True. This is because Sage tries, and succeeds, to find a place where both the objects being compared map to -- here an integer mod 4 and an integer can both be mapped to integers mod 4 (i.e. elements of Z/4Z) where they are compared and found equal. The warning is that "==" does *not* correspond to equality in any mathematical sense (it is not transitive, for example): sage: 0 == mod(0,2) True sage: mod(0,2) == 2 True sage: 0 == 2 False John > -- > Regards > Minh Van Nguyen > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
