From: Leo B. <l_b...@us...> - 2016-09-01 04:00:16
|
Richard Fateman <fa...@be...> writes: > On 8/31/2016 10:20 AM, Leo Butler wrote: >>> Yes, it would be nice, if Maxima would have the possibility to >>> >communicate in a more computer parseable way. >> The alt-display package is what you want, I think. >> See the examples in the info documentation. > The alt-display package does something useful, but is it really what > is needed? As I wrote, it satisfies his *wants*. > If Maxima is being used to produce actual symbolic expressions rather > than (say) numbers, > then the recipient R of such information is faced with expressions > like A+B. > Which means that R probably needs to know how to parse pretty-much arbitrary > "algebraic" notation expressions, following the rules of Maxima syntax. > > The expressions inside Maxima are already "parsed" into an > "intermediate language" > that explicitly represents the symbolic data. This language is > trivially printed and > read back in as strings, or could be passed as pointers to trees. > > Thus A+B*C internally is [*see note] (+ A (* B C)) > and (A+B)*C is (* (+ A B) C)) > > note: it is an easy transformation to get to the forms above, but > actually for various > reasons Maxima uses something more elaborate. > > ((mplus simp) $a ((mtimes simp) $b $c)) is the first one, for example. > > This is a stumbling block for programs calling CAS over a socket ... > if they are accessing anything "symbolic" they either have to duplicate > the parsing mechanism already in Lisp/Maxima > to obtain information from strings, or find another > way of passing more sophisticated data in streams. Or perhaps they > are linking to a CAS for some trivial response, like the one from nroots() > guaranteed to be an integer. I agree with what you have written. But curiously no frontend to Maxima takes this approach, as far as I am aware. -- Leo Butler <l_b...@us...> SDF Public Access UNIX System - http://sdf.lonestar.org |