On 14 November 2016 at 21:39, Kurt Pagani <[email protected]> wrote: > This reminds me to > https://lists.nongnu.org/archive/html/axiom-developer/2009-06/msg00002.html > > I've seen your symbolic.spad for the first time and it might be an approach > to a > topic which is haunting around for some time. How would you implement formal > sums, integrals, differentials and so on? I've tried a quich hack but it seems > not so trivial. E.g. )d op sum > > [2] (D1,SegmentBinding(D1)) -> D1 from FunctionSpaceSum(D3,D1) > if D1 has Join(FS(D3),COMBOPC,ACF,TRANFUN) and D3 has Join( > INTDOM,COMPAR,RETRACT(INT),LINEXP(INT)) > > is quite obstinate ... segment binding conversion to InputForm? > > I've always been interested in such a "purely symbolic" domain that one can > perform some basic term rewriting without fearing to be interfered by an > "autonomous" simplifier. > > See e.g. > http://lists.nongnu.org/archive/html/axiom-developer/2014-10/msg00009.html, > Attachment: syman_samples.pdf. This could be much easier with your approach. > > On the other hand, probably carrying it too far, one might use OutputForm > which > is very expressive and greatest possible "symbolic", if only there were a way > back ;) >
Of course there is no problem representing arbitrary unevaluated expressions in InputForm. That is its main purpose. Many FriCAS domains also include coercion to InputForm as a means of "pickling" values into a form that can be manipulated in purely symbolic ways and then be compiled into functions or re-evaluated by 'interpret'. It would be relatively simple to add more powerful term rewriting operators to InputForm that might make it easier to implement some types of mathematically sensible symbolic operations. But I think it is a bit dangerous to FriCAS/Axiom design goals to place too much emphasis on such symbolic manipulation. The emphasis should be on *algebra* not simply the manipulation of symbols. The problem with OutputForm as a representation is that it is deliberately designed to gloss over some of the semantics in favor of improving reading and human interpretation. Perhaps it is a bit counter intuitive that this should necessarily involve removing information but consider for example languages like LaTeX and MathML. This are not usually very suitable as input languages for computer algebra unless they are augmented with addition information encoded in various possible ways. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
