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 ;)




Am 14.11.2016 um 23:09 schrieb Bill Page:
> On 12 November 2016 at 22:31, oldk1331 <oldk1...@gmail.com> wrote:
>> I have a related question:
>>
>> Seems your question has something to do with the fact that
>> in FriCAS Expression is represented by polynomials and
>> polynomials are always expanded.
>>
>> So integrate(1/(x+1)^n,x) will be slow when n is large.
>>
>> My question is, is there a domain to express expressions
>> that are not expanded, for example "a+1/b" will not be
>> "(a*b+1)/b".
>>
> 
> Domains constructed by Expression(R), provided that R has sufficient
> algebraic structure, are designed so that evaluation produces a
> (nearly) canonical representation of an expression. This makes it very
> efficient for many purposes compared to systems that perform purely
> symbolic manipulation. This is in keeping with the orientation of
> FriCAS towards "computer algebra" rather than just "symbolic
> computatation". But there are situations when the rigorous behavior of
> the Expression domain does make things awkward and sometimes less
> efficient.
> 
> The following is an initial draft of a new domain constructor that
> implements unevaluated symbolic expressions.
> 
> https://github.com/billpage/fricas/blob/62cc95b16fb7744700ccb04f16ad9ec9f4c0b95c/src/algebra/symbolic.spad
> 
> Constructor for unevaluated symbolic expressions
> 
> Defines symbolic expressions over some domain, e.g. Symbolic Integer
> and Symbolic Expression Float, etc.  These expressions are completely
> unevaluated with no automatic simplifications. They may be simplified,
> compared as and/or converted to fully evaluated expressions in the
> appropriate Expression domain. The underlying representation is
> InputForm.
> 
> Example session:
> 
> (1) -> (a,b):Symbolic Expression Integer
>                                                                    Type: Void
> 
> (2) -> a+1/b
> 
>             1
>    (2)  a + -
>             b
>                                           Type: Symbolic(Expression(Integer))
> 
> (3) -> simplify %
> 
>         a b + 1
>    (3)  -------
>            b
>                                           Type: Symbolic(Expression(Integer))
> 
> (4) -> %%(2)=%%(3)
> 
>             1   a b + 1
>    (4)  a + - = -------
>             b      b
>                                 Type: Equation(Symbolic(Expression(Integer)))
> 
> (5) -> test %
> 
>    (5)  true
> 
> (6) -> sin(a)^2+cos(a)^2 = 1
> 
>               2         2
>    (6)  sin(a)  + cos(a)  = 1
>                                 Type: Equation(Symbolic(Expression(Integer)))
> 
> (7) -> test map(simplify,%)
> 
>    (7)  true
>                                                                 Type: Boolean
> 
> (8) -> x:Symbolic Integer := 1+2+3+4
> 
>    (8)  1 + 2 + 3 + 4
>                                                       Type: Symbolic(Integer)
> 
> (9) -> x::Integer
> 
>    (9)  10
>                                                                 Type: Integer
> 
> Of course there are more purely symbolic manipulations that could be
> very useful such as those commonly found in Maple, Mathematica and
> Sage, for example 'expand', 'combine', 'factor' etc. In many cases
> these can be implemented utilizing results produce by existing
> operations in Expression and related domains and packages and then
> converted to an appropriate InputForm as the internal representation
> of a purely Symbolic domain.
> 
> I would be very interested in comments, criticism and suggestions.
> 
> https://github.com/billpage/fricas/commit/62cc95b16fb7744700ccb04f16ad9ec9f4c0b95c.patch
> 
> Thanks.
> 
> Bill Page.
> 

-- 
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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
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