Hello, > Although it generates more processes than should be required to do the > job, perhaps this change should be included in the next release?
I think the issue on sage.math is just due to the installation of Axiom installed in "system installation" of Sage. Michael Abshoff is going to install the FriCAS 1.0.3 spkg there so it shouldn't be an issue in the near future. > Thanks! So the point is that we can obtain the string representation > of some Sage object by calling 'str' and often this string can be > passed directly to the Axiom interpreter. I think that is a good > thing, but of course whether or not this works will depend on the type > inferences done by the interpreter. For example: If neither _axiom_ or _axiom_init_ are defined for the object (in its class or superclasses), then it falls back to just trying to send the string representation of the Sage object to see if that works. For example, if you do sage: axiom(QQ) Traceback (most recent call last): ... TypeError: sage0 := Rational Field ... After adding an _axiom_init_ to sage/rings/rational_field.py, we get sage: axiom(QQ) Fraction Integer > Obviously the default conversion from a string is not correct. How can > we make the conversion from Sage to Axiom smarter in this case? Does > it mean that we need to override the _axiom_init_ method with > something more appropriate in some more specific class in Sage? Yep. It's just a matter of putting it in the right place on the class hierarchy. > So should we add _axiom_init_ to IntegerMod_int class? Something like this? ... > Maybe _axiom_init_ has to come from the Sage parent? How do I do that? > This is the kind of thing that still seems a little mysterious to me ... For IntegersMod in Sage, the right place was in the IntegerMod_abstract class. I put a patch up with these at http://trac.sagemath.org/sage_trac/ticket/4036 . > >> For more complicated things, the _axiom_ method takes in an Axiom >> interface object and returns self constructed in Axiom. >> >> class Foo(SageObject): >> def __init__(self, n): >> self.n = int(n) >> def _axiom_(self, axiom): >> return axiom(str(self.n)) >> >> This behaves the same as above. >> > > This form seems obscure to me. What is an "Axiom interface object"? By "Axiom interface object", I mean the same type of object as the "axiom" you use at the command line. sage: type(axiom) <class 'sage.interfaces.axiom.Axiom'> Each of these object corresponds to a different Axiom session. For example, sage: a1 = Axiom() sage: a2 = Axiom() sage: a1.set('x', '2') sage: a1.get('x') '2' sage: a2.get('x') 'x' sage: a2.get('x') '3' sage: a1.get('x') '2' > Why/How does this code behave the same way as the first example? When you call axiom(a), it finds the _axiom_ method and calls it. All the function has to do is construct and return the appropriate object in the Axiom session that is passed in. Since you have the actual object, you have a lot more flexibility than if you just had to return a string. (Think defining functions, etc.) --Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~----------~----~----~----~------~----~------~--~---
