Am 15.11.2016 um 22:58 schrieb Bill Page: > 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)'. >
SEI==>Symbolic Expression Integer Actually I meant D1=SEI, i.e SegmentBinding(SEI). I've tried the compiler by editing your symbolic.spad to represent a 'summation'. It will certainly work, you have more experience. >>>> >>>> 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. As it's sometimes the case we differ only in terminology. I don't really like the terms syntactic/semantic in this context, but my vocabulary is limited. I'd say Symbolic(AdmissibleType) is purely formal before transforming to AdmissibleType (which should have a meaning in Fricas). I use InputForm very often, e.g. in the theroem prover or interfacing embedded-maxima etc., so the results only have a meaning when they are transformed back to a Fricas type. You might object that (with reason) Symbolic() is "semantic" as well ... yes, that's a loop ;) > > 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. Yes, same problem as above. > >> >>> 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. > Symbolic is now explicitly exposed in frame frame1 Symbolic will be automatically loaded when needed from /home/kfp/Devel/fricas_input/spad/symbolic/SYMB.NRLIB/SYMB (1) -> SEI==>Symbolic EXPR INT Type: Void (2) -> (x,y):SEI Type: Void (3) -> (x+y)^2 2 (3) (x + y) Type: Symbolic(Expression(Integer)) (4) -> r:=(x+y)^2 2 (4) (x + y) Type: Symbolic(Expression(Integer)) (5) -> r::InputForm Internal Error The function convert with signature hashcode is missing from domain Symbolic(Expression (Integer)) (5) -> r@InputForm An expression involving @ InputForm actually evaluated to one of type Symbolic(Expression(Integer)) . Perhaps you should use :: InputForm . ... (5) -> convert(r)$SEI Internal Error The function convert with signature hashcode is missing from domain Symbolic(Expression (Integer)) (5) -> coerce(r)$SEI 2 (5) (x + y) Type: OutputForm But shouldn't be a problem ... >>> 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). > Yes, I can see your point. >> >> 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're perfectly right from this viewpoint. Let me summarize what's the difference here: when setting x:Integer, Fricas expects a value, when we set x:Symbolic(Integer) we should be able to use it like "any" Integer. In a nutshell, you should elaborate symbolic.spad, I'd certainly use it. -- 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.
