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. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
