On Sep 7, 3:58 am, Golam Mortuza Hossain <[email protected]> wrote: > IMO, minimal but functional library would be the right way to go. > From my personal experience, trying to do one small step at a time leads > to much further distance in long run rather than trying to do everything > at one go.
and on Sep 7, 4:15 am, Burcin Erocal <[email protected]> wrote: > A python interface to maxima (MaximaSymbolicRing) would be totally > awesome. Though this would be a lot of work and I don't think it is > required for the interface between Sage and Maxima. Nice. First two reactions are seemingly diametrically opposed :-) I'm not sure it's so much more work, actually. That depends on how much work it is to equip sage with a new ring. Implementing "addition", for instance, is going to be dead easy, provided you don't mind that things don't automatically simplify: def _add_(self,b): return EclObject([["MPLUS"],self,b]); In fact, it may be that Sage's standard coercion machinery makes it desirable to give the "translated to maxima" expressions a proper place in sage's mathematical structure library. The hard work in all cases is going to be the translator to/from other sage constructs, in this case probably mainly the SymbolicRing <-> Maxima translator functions (SRtoMAX and MAXtoSR are a start). For that we need: 1. A dictionary mapping SymbolicRing constructs to Maxima (both are essentially "tagged lists" (parse trees), so this is mainly mapping the tags). Currently formed by SR_ops and MAX_ops. 2. Routines to map atomic entities back and forth (symbols, constants, numeric types etc.). Currently sage's constants are hard to recognise, but I expect a few levels down this will be easy. For the rest, this is really more an ecl_to_python and a python_to_ecl problem. 3. Exceptional treatment of certain tag types (e.g. limits), because of syntactical differences. (not done at all yet) 4. Mapping over context that influences the meaning of expressions, but are not part of the expression, such as assumptions. (I don't know how either system handles this) We are always going to need those ingredients, and most of it consists of gradually populating dictionaries and adding special cases. One argument *for* implementing MaximaSymbolicRing would be that sage's ring interface is less likely to change in any major way than the implementation of its native SymbolicRing. If honestly implemented, it would also give a means to produce interesting benchmark measuring symbolic-integrals-per-second performance between different systems (if so desired). The argument against is, of course, that implementing it would be at least as much work as equipping sage with a new ring type. FInally, we need a name for the interface. I propose the completely natural: MaNIaCAL(Maxima As Non-Independent Assistive Computer Algebra-system based on Lisp) --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
