Hi there, > > In Sage, the behavior of sqrt(2) versus sqrt(4) is considered very > > reasonable > > to most users. And it does exactly what you claim is "rather bad form". > > > > sage: sqrt(2) > > sqrt(2) > > sage: sqrt(4) > > 2 > > sage: type(sqrt(2)) > > <type 'sage.symbolic.expression.Expression'> > > sage: type(sqrt(4)) > > <type 'sage.rings.integer.Integer'> > > That clears things up. Thank you. I'm disappointed. This looks like > it's rather deeply ingrained in the system. It's not just a > convenience top-level sqrt that chooses output types, the "sqrt" > method on integers does the same: > > sage: 3.sqrt().parent() > Symbolic Ring > sage: 4.sqrt().parent() > Integer Ring
I quite agree with Nils. If there is a chance to change it without breaking to much things, my vote would be the following: The *function* sqrt as a top level convenience could keep it's current behavior, but on the contrary to the current behavior, the *method* sqrt should not change the class/Parent of its result depending on its value: - ZZ(4).sqrt() should return ZZ(2) - ZZ(3).sqrt() should raise a ValueError The current result of sqrt(3) should be computed by - SR(3).sqrt() By the way, why choosing SR and not QQbar ? Cheers, Florent -- 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
