I tracked down a confusing bug in some code I was writing in Sage down to the fact that pow(a,b,m) applied to Sage Integers does not give an Integer result, but rather an object with parent the ring of integers mod m (a simple call to either int() or .lift() fixed my code).
I like this design decision or returning a congruence class, but worry that it's not adequately documented. Tracking down my bug was extremely confusing because (1) objects of IntegerMod_* classes print like ordinary integers and (2) the docs don't seem to mention that 3-argument pow on Integers produces IntegerMods. The documentation for pow is, I think, just the python documentation and says that pow(a,b,m) is equivalent to (a**b)%m but faster. That is false for Sage Integers, since % for Sage Integers produces an Integer result, not an IntegerMod result. The documentation for Integer.__pow__ doesn't mention mention the result type of the 3-argument version either. So here are my questions: Does the documentation mention this somewhere? If so, where, and why not on either pow or Integer.__pow__? Wouldn't be better for congruence classes to print as "a (mod m)" or something like that? Should 3-argument Integer.__pow__ produce congruence classes as it currently does? I like it, but some people might prefer more compatibility with standard python ints. Confusingly, perhaps, Sage also has a power_mod function that given 3 Integers produces an Integer! Maybe pow should give Integer results and power_mod should give IntegerMod results... Furthermore, if it's a good idea for pow to give modular results, should % on Sage Integers also produce modular results? -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
