[this email will likely bounce somewhere, so if it doesn't show up in some place please forward]
Martin Rubey wrote: > Dear Michael, Hi Martin, > just a short recap, whether I have understood things correctly: > > the problem you currently face with external symbolic calculus is that the > representation of the objects is not identical in SAGE and in the external > progam (Maxima). > > you are using something called "pexpect" which does the parsing. pexpect is a mechanism to talk to other executables via a pseudo tty interface. It also does parsing. > I do not see how the problem of differing representations can be resolved. Up > to now I thought that Sage simply doesn't have an "internal" representation, > and just uses the one from the external program - that's how my polymake > interface for FriCAS/Axiom works. I am not 100% clear, but I believe for elements in a symbolic ring we do not yet have a Sage internal representation. It is being written in Cython since arithmetic is probably slowed down by a factor of 10,000 by using pexpect+Maxima. That is largely the fault of pexpect. For other code like Singular or pari we can either use the library interface or pexpect, depending if the operation is available in the library or nor. So if you are multiplying two polynomials over Q[x,y] with libSingular we use Singular's computational engine directly. > If this is correct and if Sage insists on having an internal representation, > then it probably only makes sense to have external programs for "large" jobs, > where the time spent in parsing is not an issue. Either, because the result > is > not processed much further anyway, or because obtaining the result is much > more > costly than the parsing. Yes, that is the exact strategy that make sense. I gave the example with arithmetic for GAP, but any high level algorithm with little input, little output and huge computational time is well suited for a pexpect interface. > Thus, the obvious candidates for using FriCAS are integration (it beats the > commercial CAS in the elementary case, by the way) and related stuff like > solving ODE's, and guessing (ditto). Interesting, I didn't know that ;) > Please correct me, if I'm wrong. So far you got it all right. > ------------------------------------------------------------------------------- > > Apart from that, I would like to clarify a point, that might become a > misunderstanding otherwise: > > FriCAS (as far as I can control it) has a pragmatic approach what concerns the > "target language" of it's compiler and the language it's interpreter is > written > in. Currently, it's lisp, because that works, works well, seems to be > reasonably fast and works on many platforms, including MS Windows. FriCAS > builds on quite a few lisps, sbcl seems to be fastest. Yes, that is what I have gathered so far. Gaby pointed out that sbcl does tend to fail on occasion on Windows since it needs contiguous memory and if some DLL is mapped into the wrong area its memory allocation will fail. We have been bitten by Sage+Cygwin by similar problems since the total memory available to Cygwin is limited to roughly 1.3GB and since we build a massive amount of extension libraries [180 extension from Sage + others] you do have library address space collisions. You can work around that via a rebase tool for DLLs, but it is certainly a peculiar aspect of Windows. > HOWEVER: FriCAS has (almost) no mathematics written in lisp, not even for > bootstrapping. We use bignums, arrays, floats, strings, symbols from lisp, > but > that's about it. > > The goals of FriCAS and open-axiom are quite similar, as far as I can tell. I > truly hope that the collaboration of the two will continue. Yes. I was surprised "back then" when the Axiom for happened that it was followed by a second one. But this is certainly neither the time nor the place to get into this. My usual limit is one flame war per week ;) > ------------------------------------------------------------------------------- > > Finally, concerning lisp: is it correct that Sage would not mind (for the > moment) a default lisp, that builds the Sage way, but would use a "better > suited" lisp, if available and installed on the target machine? (in fact, > that's how FriCAS and, as far as I know, open-axiom work currently, anyway.) I had some off-list exchange with Robert Dodier and he will try to look into building Maxima on top of ecl [it was renamed from ecls and I didn't notice :)] - Michael Goffioul did some work in that direction in 2005 and Robert will see how close that work and his own from roughly January 2008 will get him to a working Maxima. He also stated that he will likely spend more time on this during this weekend. I just checked into some more details of ecl and Juan Jose Garcia-Ripoll just posted the following to the ecls mailing list: > I have uploaded a copy of the talk I gave two days ago at the European > Common Lisp Meeting in Amsterdam. It can be reached here > http://ecls.wiki.sourceforge.net/space/showimage/eclm2008.pdf It is a very nice presentation and illustrates the differences to gcl for example regarding approach to portability and memory management. ecl depends on on boehmgc, which is licensed under a GPL compatible license [X11 like]. elc itself is LGPL V2+, so from that standpoint I see no objection to replace clisp with ecl once Maxima is ready. The work on this will likely also start this weekend by initially providing an optional spkg for ecl as well as boehmgc. The interesting connection here is that M2 also needs boehmgc and that would knock the unsatisfied dependencies of M2 not in Sage down to gdbm. Since all the components M2 depends upon in Sage are either working with or getting ported to MSVC in 32 & 64 bit mode and the M2 code is fairly portable this opens up the possibility of M2 on native Windows provided we get gdbm working. I didn't check into that, but I guess overall it is good news for M2 ;) So: What should you do: a) wait a week or two for ecls and gdbm to become optional b) build an optional FriCAS/OpenAxiom spkg using ecls c) write a pexpect interface to use integration/ODE/guess if that is something where you see FriCAS/OpenAxiom as "better than anything else". In parallel take a look at http://wiki.sagemath.org/spkg/InclusionProcedure and write some proposal *why* FriCAS/OpenAxiom should become part of standard Sage and *what* is should/can [via pexpect] do. The "Build" section can be safely ignored assuming you do not depend on anything beyond ecls. Then eventually it will come down to the vote and if for example FriCAS beats Maxima and the 4Ms at integration I would consider it very like that it could make it in. FriCAS full [without gcl] weighs in at 9MB, so if you can strip out unneeded parts for an initial bare bone distribution it would be great. I can certainly help with building spkgs and so on. The best way to do this is in #sage-devel. Since I live on PST time [and go to bed late even for that time zone] the best time to catch me is either before noon or around 8PM CET. I want to point out that this is the optimal way it could go for you guys, i.e. you might get voted down [for now], it could also take a while to go from optional to default and so on. I just don't want to give you false hope, but with the build issue under control and the potential for fast integration, ODEs and guess, the willingness on your end to get things done I am now seeing this in a much more positive light than even 24 hours ago. > Martin > Cheers, Michael > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
