On 15 November 2016 at 12:01, Kurt Pagani <[email protected]> wrote: > Am 15.11.2016 um 14:12 schrieb Bill Page:
>> 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? Yes, there already is such a conversion but it isn't very pretty, e.g. (1) -> x:SegmentBinding(Integer) := equation('x,1..10) (1) x= 1..10 Type: SegmentBinding(Integer) (2) -> x::InputForm (2) (($elt (SegmentBinding (Integer)) equation) x (($elt (Segment (Integer)) SEGMENT) 1 10)) Type: InputForm This doesn't work unless you specify 'SegmentBinding(Integer)' because for some reason 'PositiveInteger' does not export 'ConvertibleTo(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'. > > That's beyond controversy. My point was how to represent a purely syntactical > structure (symbolic if you want) best suited for certain manipulations. Of > course we have rewrite rules and kernels, but those serve another purpose. > Of course at a fundamental/primitive level in FriCAS things are represented by Lisp s-expressions. There are abstracted as List, Record and Union data structures in SPAD which can be used recursively together with Rep to define abstract data structures of various kinds. This is "syntactic" in at least the general sense and I am not sure what more might be desirable for the example that you gave. If by "syntactic" you meant strictly linear list structures or strings I think that is another story. There are some Lisp-ish style operations exported by InputForm via SExpression. I am sure that higher level operations are possible and may be desirable. But the most important aspect of InputForm is that InputForm values may be interpreted by FriCAS evaluation. This gives InputForm a type of operational semantics. The interesting thing is that one can reverse this process and create InputForm values from these "semantic" domains. > >> 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. > > Then let's do it. As already remarked I find your approach promising. What I > can't see yet is a simple method to atomize objects in "Symbolic Expression > Integer", for example. Converting back to InputForm? That would mean analyzing > s-expressions (admittedly easier than kernels). > Yes that is already automatically implemented because "Symbolic" domain constructor uses InputForm as the underlying representation. >> 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. > > There is no doubt about that. There are a lot of tools that can do what we > here > are talking about. Nevertheless it doesn't do any harm to have it in the tool > chest, especially if we can propagate the expressions into the "semantic" > area, > what seems feasible with InputForm rather than with OutputForm for instance. > OK. >> >> 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 additional information encoded in >> various possible ways. >> Consider the following example of Factor (1) -> f:=factor(a^2+2*a*b+b^2) 2 (1) (b + a) Type: Factored(Polynomial(Integer)) (2) -> f::InputForm (2) (primeFactor (:: (+ b a) (Polynomial (Integer))) 2) Type: InputForm (3) -> f::OutputForm pretend InputForm (3) (^ (+ b a) 2) Type: InputForm (4) -> interpret(%% 2) 2 (4) (b + a) Type: Factored(Polynomial(Integer)) (5) -> interpret(%% 3) 2 2 (5) b + 2a b + a Type: Polynomial(Integer) (6) -> %%(3) pretend OutputForm 2 (6) (b + a) Type: OutputForm The example in (2) above provides semantic information in the form of function calls that are evaluated in the standard context of the FriCAS interpreter. The result in (6) looks the same as in (1) and (4) but evaluating (3) on the other hand yields something equivalent but different - in this case (almost) the same as the original value passed to 'factor' in (1). > > That's the crunch question, indeed. Do we need "semantics" at all? Probably > not > before doing real world calculations. I very like the quotation given in the > thread mentioned earlier: > > """ > I see OpenAxiom as aiming at computational mathematics as opposed to > just being specialized for algebraic computations only. > > -- Gaby > """ Hmmm... from my point of view all computations on a digital computer are at a fundamental level "symbolic", i.e. things represented by strings of bits. What is important is the process of abstraction. That is where "semantics" enters and why we call a certain machine instruction "addition" and another "multiplication", etc. It seems to me that the design of computer algebra systems like FriCAS/Axiom just take this entire process to higher and higher levels. -- 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.
