On Oct 31, 8:47 am, mmarco <mma...@unizar.es> wrote: > for i in range(10): > print cos(i).n() ... > Besides, 0 should be converted to Integer(0) by the > preparser, right? so the criterion of keeping the input type also > points to the same direction.
*keeping* input types would still let your example fail, since range(10) produces ints, not Integers, so the concept might need some interpretation. This trips up other functions as well: sage: type(sqrt(4)) <type 'sage.rings.integer.Integer'> sage: type(sqrt(int(4))) <type 'sage.symbolic.expression.Expression'> which indicates that sqrt special-cases "Integer" but not "int". They are actually implemented differently: sage: type(sin) <class 'sage.functions.trig.Function_sin'> sage: type(sqrt) <type 'function'> Wouldn't it be an idea to not put all the complicated heuristics of what to do depending on different input types into pynac but into purpose-built top-level wrapping functions such as sqrt? That way, pynac would only have to care about symbolic inputs. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
