> Is there some easy way I could have figured out that m would respond > to the message `apply_map'? > (Or whatever messages are called in the post-Smalltalk era.)
In Python, they're known as methods and they come associated with an object based on its type. To get a list of all the methods that m has, you would type in m. and then press tab. > However, > 1.rational_simplify() > causes an error. The explanation is that > type(((x^2-1)/(x-1)-x).rational_simplify()) > is > <class 'sage.calculus.calculus.SymbolicConstant'> > whereas > type(1) > is > <type 'sage.rings.integer.Integer'> You are correct on this. > But it seems like this could be a more natural and useful way to > handle an operation like ratsimp. This is because there is a pretty clean split in Sage between the symbolic stuff (which is using Maxima) and everything else. All the symbolic stuff lives in the SymbolicExpressionRing. sage: SR = SymbolicExpressionRing() sage: a = SR(1) sage: type(a) <class 'sage.calculus.calculus.SymbolicConstant'> sage: a 1 sage: a.rational_simplify() 1 > > Maybe the problem is that I just don't have a model yet that would > allow me to predict, for example, that > to find the length of something I should feed it to the function len, > rather than sending it the message len(), > whereas if I want to do something to each entry of a matrix, I should > send a message apply_map to the > matrix, rather than feeding the matrix to a function called apply_map. Pretty much everything is in the methods (or at least should be). There are some global level functions for convenience that basically just call the object's method. len() is a builtin Python function and will call the objects .__len__() method. > to know or care, as apparently they do in sage. In which case I think > it might work better to try to stick with functions > rather than messages, where possible. Under Python's object-oriented approach, the objects and methods are the preferred way of handling things. And, when it comes to working with a wide range of types as Sage does, the code is much cleaner and easier to work with. > > One thing I know I'm going to miss from Mathematica is the loosely > binding operator \\, as in f \\ g, which is another way of writing > g[f]. This allows you to build up a computation by writing first > things first. And because of the loose binding, you can write > longcomplicatedexpression \\ ratsimp > without fear that ratsimp will stingily only simplify the denominator > of the expression. Because Sage adopts Python's syntax, nothing exactly like that will be added to Sage. On the other hand, the Python interpreter regards _ as the last object. You could do something like this: sage: (x^2-1)/(x-1)-x (x^2 - 1)/(x - 1) - x sage: _.rational_simplify() 1 --Mike --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@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-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~----------~----~----~----~------~----~------~--~---
