Dear Ralf,
Thanks very much for the detailed explanation of
some basic differences between fricas and other CASs.
It really is a major difference that fricas is not
using some kind of expression tree, as is the case
for other CASs.
It certainly seems worthwhile to implement expression
trees in a powerful system like fricas.
If fricas can at least match the symbolic expression
manipulation capabilities of basic CASs (and also do
many other things) then fricas will become an attractive
option for many users.
Best regards,
Constantine.
----- Original Message -----
From: "Ralf Hemmecke" <r...@hemmecke.org>
To: fricas-devel@googlegroups.com
Sent: Thursday, January 26, 2017 2:42:13 PM
Subject: [fricas-devel] internal representation of elements in FriCAS
On 01/26/2017 12:14 PM, Constantine Frangos wrote:
> %I was not aware of this behaviour. However, I believe that fricas should not
> %automatically expand expressions that the user inputs. If this can be
> %modified then it would be very helpful.
Yes, you can wish this, but if you knew the internals of FriCAS a bit
more, then you would understand why this is not a good wish.
FriCAS is different from most other computer algebra systems. While the
basic datastructure in other CAS is (more or less) an expression tree,
it's easy there to "not simplify" the input of the user. FriCAS
(usually) works internally with specific representations. These specific
representations are connected to (what is in FriCAS called) a domain.
Look at the output of your trigonometric stuff. It says at the end:
Type: Expression(Integer)
In other words this "Expression(Integer)" domain imposes a certain
internal representation of the user input.
Let me give a little example. Take SparseUnivariatePolynomial.
(1) -> P ==> SparseUnivariatePolynomial(Integer)
Type: Void
(2) -> x: P := monomial(1,1)
(2) ?
Type: SparseUnivariatePolynomial(Integer)
(3) -> p: P := (x+1)^5
5 4 3 2
(3) ? + 5? + 10? + 10? + 5? + 1
Type: SparseUnivariatePolynomial(Integer)
You might ask, why cannot FriCAS keep this polynomial unexpanded. The
answer is simple if you look inside the definition of
SparseUnivariatePolynomial.
https://github.com/hemmecke/fricas/blob/master-hemmecke/src/algebra//poly.spad#L689
You find
Term ==> Record(k : NonNegativeInteger, c : R)
Rep := List Term
which means that p is represented as a list of records
[[5,1],[4,5],[3,10],[2,10],[1,5],[0,1]].
The domain simply has no means to represent (x+1)^5 in a non-expanded
form. It is not an expressin tree!
Of course, since everything in FriCAS can be programmed, one can invent
a domain that has a more general datastructure (Rep) so that it would
also store an unexpanded from of (x+1)^5.
But what would be the decision of when to expand and when not to expand?
FriCAS (mostly) takes the route to store only "canonical forms" of
expressions (if that is possible). And FriCAS is not bound to just one
canonical form. It can have different canonical forms and they depend on
the domain (in FriCAS "domain" comes from "domain of computation") that
you are working with / working in. The domain basically gives you a
context of your computation. Other CAS usually don't have this flexibility.
Another example is GeneralDistributedMultivariatePolynomial
https://github.com/hemmecke/fricas/blob/master-hemmecke/src/algebra//gdpoly.spad#L36
and SparseMultivariatePolynomial
https://github.com/hemmecke/fricas/blob/master-hemmecke/src/algebra//multpoly.spad#L105
Look at their representations. These different representations make a
difference. For example, one would usually use a distributed form for
Buchberger's algorithm where a recursive representation (as
SparseMultivariatePolynomial is) imposes a tremendous complexity
overhead when trying to determine the exponent vector of the variables
of the "leading term". In other algorithms SparseMultivariatePolynomial
have advantage over the distributed representation. It simply depends on
the algorithm that one wants to apply.
I'm sure that excursion doesn't very much help you to solve your
original problem, but I hope it helped you to understand a bit better
the difference of FriCAS to other systems like Mathematica, Maple,
Maxima, Reduce, etc.
Nothing prevents us from implementing an expression-tree-approach in
FriCAS, actually "Expression(Integer)" is pretty close but NOT truely an
expression tree. You could then have non-expanded user input. But nobody
has done so far. But remember, computation with expression trees is
harder (and usually more complex) for certain algorithms. And for
general expression trees, we don't yet have algorithms for
simplification. Note that what "simplification" means is usually
dependent on the user. -- Do I want sin(2*x) --> 2*sin(x)*cos(x) or
rather the reverse direction? -- That is why do don't have automatic
simplification of this form in FriCAS.
And, in fact, the strength of FriCAS lies in algebraic computations and
not so much in symbolic formula manipulations.
Ralf
--
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.
--
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.
