On Mon, Aug 18, 2008 at 11:58 PM, Bill Page <[EMAIL PROTECTED]> wrote: > > On Mon, Aug 18, 2008 at 1:51 PM, Ondrej Certik wrote: >> >> On Mon, Aug 18, 2008 at 7:08 PM, Bill Page wrote: >>> >>> Ok, thanks for the example. Yes I admit that using Cython this way >>> is quite nice. It makes me think that maybe it would be interesting >>> to write such Cython wrappers for calling larger parts of Sage from >>> some external program (such as FriCAS) this way. >> >> Yes, exactly. I always wanted to call Sage like a library. >> >>> But these sort of conversions are exactly the kind of thing to which >>> I was referring. In your example, the conversion is quite simple but >>> it even looks a little clumsy in this case. My main point in these >>> comments, is that when converting between two different high-level >>> representations of some more complex mathematical object, e.g. >>> a matrix of p-adic polynomials, etc. these conversions can >>> potentially dominate the interface. >> >> Agree. So what's the other option? >> > > The only "other option" that I can think of is something like Martin > Rubey suggested near the start of this thread: a new domain in FriCAS > named 'SAGEForm'. The representations used in 'SAGEForm' would > correspond directly to actual Sage data structures. In order to do > this in a general manner it would be very convenient for FriCAS to be > able to call Sage functions via Cython wrappers in the manner you have > described in this thread. The 'SAGEForm' domain would provide an > application interface to Sage for the rest of the FriCAS system. This > API would have to provide something like a shared buffer in which to > make the native Sage representation that it constructs available to > the rest of Sage. > > Each FriCAS domain that you want to be able to represent directly in > Sage would have to provide an operation such as: > > coerce: % -> SAGEForm > > (similar to 'coerce: % -> OutputForm' and 'coerce: % -> InputForm'). > This operation would convert values of that domain to it's > corresponding representation in Sage and in the case of complex "type > towers" in Axiom, these conversions could be called recursively. It > also should be possible to write a default coercion from 'InputForm' > to 'SAGEForm' that would work in some cases. 'InputForm' is the > existing domain in FriCAS that represents input to the Axiom > interpreter. > > In fact using 'InputForm' in this way is exactly what the current > 'axiom.py' interface does now. Computed FriCAS/Axiom values are > converted to 'InputForm' (which is just a Lisp 'SExpression') and then > from that form to the unparsed linear string form which is returned to > Sage (over the pty serial interface). The representation in > 'InputForm' eliminates almost all type information but in a lot of > cases this is sufficient for Sage to convert to its native form since > when converting this representation backwards, Sage makes many of the > same type inferences that are made by the Axiom interpreter. But > rather than converting 'InputForm' to a linear string representation > and back, we want to go directly to a Sage data structure. This means > that in many domains a simple generic conversion (e.g. integer > literals to integer values) might not be the best one can do. > Important semantic information relevant to the representation might be > lost. In this case the domain could provide it's own direct coercion > to 'SAGEForm'. > > In this proposed solution, writing SAGEForm in FriCAS is where most of > the work would be done.
Ok. Happy hacking. :) Ondrej --~--~---------~--~----~------------~-------~--~----~ 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/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
