On Tuesday, May 31, 2016 at 9:37:48 AM UTC-7, Volker Braun wrote: > > This was a request at sd74: > > sage: 42 mod 8 > 2 > sage: type(42 mod 8) > <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> > > Thoughts? Ticket is at http://trac.sagemath.org/ticket/20735 > <http://www.google.com/url?q=http%3A%2F%2Ftrac.sagemath.org%2Fticket%2F20735&sa=D&sntz=1&usg=AFQjCNFKIIysssozH63FUdYU0XKQ9FJGtg> >
I can see a few negatives: - confusion with "%" operator and with "mod" operators in other languages (which are generally "remainder" operators) - once we have it for integers, I am sure people would start to expect it to work in other situations too (where preparsing is harder) - the current implementation is a smart idea, but it's not "highest precedence": 3^5 mod 2 - you're introducing a new reserved word in sage, which will break previous code. - to be an infix operator, it has to respect parentheses, so (2+3) mod (3*(7+8)^2-19) should work (and then we're down the drain again, because regex isn't powerful enough for parentheses). I think it's an interesting experiment, but at the moment I don't think the advantages (a slightly more convenient way of creating elements in Z/nZ by having a shorthand notation for IntegerRing(n).one()) outweigh the problems above. I think the observation that having extremely concise access to the appropriate 1 and then let coercion do the job, is a very useful one. So if we'd spell it 42 * mod(8) you're almost there. The implementation could possibly by def mod(N): return parent(N).quo(N).one() You have to write the parentheses (but honestly, most math typesets (mod N) anyway, and usually has very low precedence because it qualifies the entire formula) and the multiplication sign (unless you're crazy enough to activate implicit multiplication), but in return there's no extra preparsing, no reserved keyword, and complete transparency to what it does and higher generality (because it will work for polynomials too). With a little more work we could also have it work for ideals. So, +1 for the whole suggestion, but I think we should go with the convenience function instead of preparsing. There's a reason why python3 made "print" into a function instead of a separate syntactic construct. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
