oldk1331 wrote: >> I'm not familiar with SAGE, but I assume interoperability of SAGE >> is based on string and parsing? And FriCAS is not a "first class ciziten" >> of SAGE? > > 'Martin R' wrote: > both of these assertions are currently true. apparently, there is not > enough interest in using fricas from sage. although i advertised a little > to reuse existing routines (in particular, guessing), i got hardly any > feedback (there is some, see: https://trac.sagemath.org/ticket/22072). >
I have used FriCAS and Sage quite extensively and have done development in both, being responsible for the first version of the Sage-Axiom interface (> 10 years ago). Over the years there were some improvements to the Axiom/FriCAS interface made by several people and most recently a major rewrite of the FriCAS interface by Martin. Initially I was rather surprised by the apparently lack of interest - both in the Sage project and in the FriCAS project. For me Sage provided a number of things that Axiom/FriCAS still does not have, e.g. a good web-based notebook interface (not withstanding the more recent and excellent Jupyter interface developed by Kurt) and associated graphics. I infrequently used Sage as a bridge to/from FriCAS from/to other tools such as Singular, Ocatve and Sympy. > part of the problem is that i do not have enough energy to program a proper > - non-string-parsing - interface, although waldek showed that this is > possible. In particular, sending long lists (for instance, of polynomials) > to fricas is currently extremely inefficient. Volunteers very welcome. > I have never found the interface itself to be a constraint. In the context of interoperability between radically different packages I think it is misleading to describe "string parsing" as necessarily seriously inefficient. In principle parsing Lisp s-expressions does not require a great deal of CPU. Most of the inefficiency has to do with the the use of "convenience" tools such as regular expression pattern matching instead of an actual parser. There is however the related issue of the pexpect tty-capture method for communicating between processes. This is notoriously inefficient and error-prone. This could be solved by using a well-designed socket interface (which is already available in FriCAS and used internally by HyperDoc), or by calling a shared library that runs FriCAS in the same process (previously mentioned in this thread). Sage interfaces with Maxima using both pexpect and by calling directly to the Maxima loaded as a shared library. But as I understand it since Sage is written in Python even calls to Maxima via the shared library interface involve some form of parsing and construction of Lisp s-expressions. >> Maybe, just maybe, FriCAS and Maxima can inter-operate >> at a higher level (Lisp level, S expression), and give interesting result. > > The question is who is your audience, this defines what's interesting. > I think Martin has a very good point. I cannot imagine any really convincing use of Maxima called from within FriCAS. For sure FriCAS does lack many convenient features for "symbolic computation", concentrating instead on a more "algebraic" version of computer algebra. For the most part I think this is the major strength of FriCAS but recently I have done some serious experiments with the idea of improving symbolic computation in FriCAS. I think there are some interesting things that can be done quite easily within FriCAS to provide a more symbolic front-end for example to more algebraic domains like Expression. Please pardon the expression but I think that resorting to Maxima for this sort of thing would be rather a "can of worms". Nonetheless personally I would be very interested in a Sage/FriCAS interface that called FriCAS as a library. Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
