> > +1. And in fact it probably should define y as a variable even if you > > just do differentiate(y^3). > > For the record, that will never happen by default in Sage. That goes > along with choosing Python as the user language of Sage. Some > reasons: > > 1. Except for ^-->** and int/float wrapping, I think the Sage > preparser _only_ transforms expressions that would be syntax errors in > Python into valid expressions. Since differentiate(y^3) is valid > Python, the preparser shouldn't touch it. > > 2. If you make differentiate(y^3) automatically define y, then in any > code anywhere, anytime one makes a typo in a function name or variable > name, that variable will magically spring into existence and the code > may continue to run producing wrong answers. This goes against the > "explicit is better than implicit" maxim of Python.
These reasons are very sensible. I wasn't aware of them, but that makes sense. #1 is very interesting! > Are you saying the syntax of Mathematica and Maple have *changed* > significantly since those days? What "things have gotten better"? I > have the impression that the syntax of both Mathematica and Maple's > languages are nearly identical to what they were 15 years ago. > Well, at any rate they seem slicker to me. If they are the same, then I guess I still wouldn't be using them - maybe? It's hard to deal with such hypotheticals, now that I know Python; I just know that really turned me off at the time, though. That said, the "clickable" aspect of current Maple is intriguing and sometimes makes things easy, though it is VERY busy. Palettes etc. can help too with routine but long-to-type things - which is why tab-completion is so wonderful in Sage, it is sort of an intelligent non-GUI response to palettes. > > problem, which I can understand as being interpreted as a problem, it > > seems like this proposal is solving a problem that doesn't exist. The > > only ambiguity here is for someone doing > > sage: (y^3).integrate() > > 3*y^2 > > who wanted > > 0 > > because the variable was x, but such a user would presumably know that > > the variable of choice makes a difference anyway and would have done > > sage: (y^3).integrate(y) > > anyway. Or am I missing something? Maybe something in Pynac would > > break otherwise? I would be very open to seeing a technical argument > > for this. > > The above is language design, and in Sage development we do not have > to do language design, since Python is the language. (Except for a few > small conveniences without which mathematics becomes way too painful, > e.g., if 1/3 evaluates to 0.) > Understood. But my understanding of Python is that sage: (x^3).integrate() is perfectly valid Python, even perhaps just as Pythonic as sage: (x^3).integrate(x) if there is a way internally to determine what should be passed to the keyword/input var if there is ambiguity? So at least both should be possible, even if one is "official". Again, I am maybe missing something here due to my knowing just enough Python, so it would be very helpful to get it cleared up in case it comes up in an unrelated context. Thanks! - kcrisman --~--~---------~--~----~------------~-------~--~----~ 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 For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
