On Mon, Sep 15, 2008 at 2:52 PM, Martin Rubey wrote: > ... > Bill Page wrote: >> The only other alternative for _sage_ in axiom.py that I can see would be >> to write something that interprets the S-expression output of InputForm >> directly. > > This may be necessary anyway. I think the plan should be as follows: as > you said already, we would like to have interpret(x::INFORM) equal to the > result of evaluating x (in a fresh environment). I believe, to make this work > properly, x::INFORM should be fully type-decorated. It seems that this is > also the current strategy, some examples below. >
Ok, comments on examples below. After reviewing this, I am not sure what "fully type-decorated" should mean. > Then, we can implement a package SagePackage analogous to OutputPackage, > that exports a single function sage: INFORM -> String. Actually, maybe it's > better to implement this in sage, because it should be possible to pass > INFORM objects as python nested lists of symbols, without going to strings? > Well, in the current implemention all things are ultimately passed as strings through the pty interface, so this does not make any difference in terms of efficiency. But conceptually I think make sense to design things "as if" we were able to do this. Eventually, maybe we will be able to call Axiom directly from Sage and to pass objects via shared memory. Since Python is such a widely used language, out there on the web are people who have already dealt with passing Lisp S-expressions to Python, e.g. http://www.clsp.jhu.edu/~edrabek/utils/ > Martin > > (4) -> (factor(x^2-1))::INFORM > > (4) > (* (primeFactor (:: (+ x - 1) (Polynomial (Integer))) 1) > (primeFactor (:: (+ x 1) (Polynomial (Integer))) 1)) > Type: InputForm If we wanted this to be "fully decorated" why not this? (* (primeFactor (:: (+ (:: x Symbol) - (:: 1 Integer)) (Polynomial (Integer))) (:: 1 Integer)) (primeFactor (:: (+ (:: x Symbol) (:: 1 Integer)) (Polynomial (Integer))) (::1 Integer))) How much can/should be assumed about the library, e.g. the existence and signature of 'primeFactor' and the coercions that will be automatically applied by the interpreter? > (10) -> (1::COMPLEX INT)::INFORM > > (10) (complex 1 0) > Type: InputForm > Here we do not see any type decorations. Do we say this is ok since the signature of 'complex' is known? But 'complex' comes from Complex(R) for some parameter R that is given here only implicitly. > I think for aggregates we can have a general rule, but we need a way to > specify > package calls > > (15) -> construct([1,2,3])$PRIMARR INT::INFORM > Internal Error > The function convert with signature hashcode is missing from domain > PrimitiveArray(Integer) > > should be > > (29) -> [(packageCall('construct)$INFORM1 PRIMARR INT)::SEX, > f::SEX]::SEX::INFORM > > (32) (($elt (PrimitiveArray (Integer)) construct) (construct 1 2 3)) > Type: InputForm > (29) -> interpret % > > (33) [1,2,3] > Type: PrimitiveArray Integer > Yes, I think this is important. I think we also need some way to do Axiom package calls from Sage. For example maybe axiom.Complex(Float).sin(1) should be evaluated in Axiom like: sin(1)$Complex(Float) To do this I think we need a new class defined in axiom.py to specifically represent packages and domains. But right now we get sage: axiom.Complex(Float) --------------------------------------------------------------------------- NameError Traceback (most recent call last) /home/page/<ipython console> in <module>() NameError: name 'Float' is not defined > the following looks fishy, because it forgets the type information: > > (13) -> [x,y,z]::List OVAR([x,y,z,q])::INFORM > > (13) (construct x y z) > Type: InputForm I agree. The question is: how much type information do we want in InputForm. Also, I wonder if specifying only coercions and converisons via the (:: ... ) construct is a good idea. Finally, I think this overlaps some work being done by Gaby in OpenAxiom. OpenAxiom has a new domain called an typed abstract syntax tree which is specifically intended to capture this kind of type information. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
