Quoting Bill Hart : > ... > What worries me is the following trace: > > sage: R=ZZ['y']; > sage: f=(1+y+y^2)*(2+y^2) > --------------------------------------------------------------------------- > Traceback (most recent call last) > /home/wbhart/ in () > : name 'y' is not defined >
I had a similar reaction the first time I saw this in Sage. > Now I see that if I do this with 'x' instead of 'y', it works, since x > is defined as a universal indeterminate from the time SAGE starts, > as William arranged. Although I understand that 'x' can be easily re-used since Sage is dynamically typed etc. pre-defining a common generic symbol like 'x' but not 'y' seems very odd to me and fails the principle of least surprise. > > I think I now also understand why this problem is difficult to resolve. > IPython is an interpreted, dynamically typed language. I don't think this is an issue. Dynamic typing in fact can provide several solutions. > > Since y is not defined as a variable in the trace above but only as a > text string, there is no way to set y to be a variable without making > adjustments to the preprocessor. > No. I don't think the Sage pre-processor is relevant here. The issue is deeper. Like all things in Python, strings are a member of some class. A class provides a collection of "methods" (functions) which determine what one can do with the members of the class. Some of these methods are called implicitly as a result of "syntactic sugar" in the Python language, so in some cases the presence of these methods may not be so obvious. > ... > This may seem like a convoluted solution, but it has some good > features: > The mechanism which you suggest in your email actually is trying to work-a-round features that are already built in to Python. In particular there are methods called "coercions" which allow members of one type to be converted on-the-fly to members of another class. One possible way of allowing 'x' and 'y' to still be strings but permit them to represent polynomials in the the appropriate context would be to provide such a coercion. This is basically the approach used by the Axiom interpreter. But one word of warning: I think designing a sensible system of automatic coercions is a difficult (and largely unsolved problem) in programming language design. Ad hoc inventions of such coercions can sometimes lead to quite unexpected behavior and again violate the prinicple of least surprise... We certainly also see that in the Axiom interpreter. :-( Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
