Again, here is another draft. The latest version of the code is here:

https://github.com/billpage/fricas/commit/c22aa634311e19153681b02ff02f3a6a02033d64

but it is still far from completion.

On 15 November 2016 at 18:02, Kurt Pagani <[email protected]> wrote:
> 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?
>>
> ...
> 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.
>

Unfortunately this doesn't quite work yet ...

(1) -> sum(x::SymbolicExpression(Integer),x=1..10)

        0   0
   (1)  - - -
        1   1
                                            Type: SymbolicExpression(Integer)

but I am still working on it.  Of course the following sort of thing is OK

(2) -> reduce(+,[n::SEXPR INT for n in 1..10])

   (2)  1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10
                                            Type: SymbolicExpression(Integer)


>>
>> Yes that is already automatically implemented because "Symbolic"
>> domain constructor uses InputForm as the underlying representation.
>>
>

The example you have now works.

(3) -> SEI==>SymbolicExpression Integer
                                                                   Type: Void
(4) -> (x,y):SEI
                                                                   Type: Void
(5) -> r:=(x+y)^2

               2
   (5)  (x + y)
                                            Type: SymbolicExpression(Integer)
(6) ->  r::InputForm

   (6)  (^ (+ x y) 2)
                                                              Type: InputForm


>>
>> 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
>> ...
>> 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. ...

In another commit

https://github.com/billpage/fricas/commit/8d06c50a84a0f660a94f5c1ff18f8f36fc848200

we exploit the above so that

(7) -> s := simplify r

         2           2
   (7)  y  + 2x y + x
                                            Type: SymbolicExpression(Integer)

(8) -> factor s

               2
   (8)  (y + x)
                                            Type: SymbolicExpression(Integer)

This code is also "bad" in the sense mentioned by Waldek and should be
replaced with something more robust that does not depend on the
particular representation of OutputForm.

But in the meantime you will notice that I did manage to write a
better version of the coerce to OutputForm that avoids making such
assumptions.

> ... 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.
>

I am not really sure if what I started with makes sense. In contrast
to my original Symbolic constructor, in this new version
SymbolicExpression does not try to make everything "symbolic" but
rather only those domains which can also be Expression.  The
difference between Expression and SymbolicExpression is intended to be
only that the expression remains unevaluated but otherwise it is
treated exactly like Expression. The thing that I began to worry about
was what exactly should

  x:Symbolic(Integer)

mean.  For example does the Symbolic(Integer) domain contain
expressions like 'sin(x)' and 'sqrt(x)' ? If we answer "no" then it
seems to me that the usefulness of such a domain is extremely limited.

What do you think?

-- 
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.

Reply via email to