About a year ago I did just what RJF is suggesting by using* embeddable Maxima *(https://github.com/nilqed/embeddable-maxima) via QuickLisp and a simple interface (https://github.com/nilqed/fricas_input/tree/master/spad/maxima) inspired by RJF's Mockmma (actually I reused a lot of code from there). The goal was to use Rubi form FriCAS. I did this just to show feasibility or for fun if you like. I'm not really a fan of interfacing other systems for various reasons unless it is inevitable.
> Nonetheless personally I would be very interested in a Sage/FriCAS > interface that called FriCAS as a library. I think there are a lot of possibilities to get such an interface (easiest "CL<->Python" seems to me using the library as a web service https://github.com/nilqed/webSPAD), although I wouldn't say that Python syntax is superior to spad ;) A more logical approach might be uniting the lisp based systems along the lines of MockMMA which makes an amazing usage of the CL parser. Back to the topic I dare say that trig simplification is not very satisfactory in most systems (including maxima, reduce etc.) as the examples in http://www.sciencedirect.com/science/article/pii/S0895717706001609 demonstrate. In a quick hack I cooked the (rule based) recipe from the paper cited above (trigsimp.spad), although I've found some gaps in it. Googling about those inconsistencies I accidentally discovered that SymPy uses this method as well :) https://github.com/sympy/sympy/blob/master/sympy/simplify/fu.py (the author there also remarked that certain points were not clear enough). Nevertheless, the method might provide good results when combined with your new SEXPR domain (at the moment it does not work as wished because FriCAS's simplifier interferes from time to time). I guess this thread has eventually shown that FriCAs is capable to shape any trigonometric expression with modest effort. Still most important seems to me "normalization" to prove equality (as Waldek suggested). On Tuesday, 21 February 2017 17:52:49 UTC+1, Bill Page wrote: > > 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.
trigsimp.spad
Description: Binary data
