[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: Advantage of Types and different representations
From: |
Martin Rubey |
Subject: |
[Axiom-developer] Re: Advantage of Types and different representations |
Date: |
28 Mar 2007 12:59:15 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
Dear all,
Please reply to address@hidden
"Ondrej Certik" <address@hidden> writes:
> > 2
> > 3x + 2x + 18
> > -------------
> > 6
> > Type: Fraction Polynomial Integer
> The above expressions can be assembled just from these 4 types (or classes in
> SymPy): Add, Mul, Pow, Integer
>
> what is the advantage to introduce more classes, like Polynomial Fraction
> Integer or Fraction Polynomial Integer?
You get a normal form for free, keeping a lot of flexibility. Apart from that,
it is not correct that we introduce a class "Fraction Polynomial Integer". We
introduce a function "Fraction", a function "Polynomial" and a function
"Integer".
A normal form for "expressions" composed with Add, Mul, Pow, Integer does not
exist, if I am not mistaken. Using types, you can very easily restrict
"attention" to classes where normal forms do exist.
Maybe polynomials are a bad example, since they are so well known. I propose
another example: Algebraic Differential Equations. Although they do not allow a
normal form, it seems. But you can still test for zero.
It would not take so much time to implement a domain that deals with such
functions. And, I guess, in SymPy, you would not be able to distinguish an ADE
from any other "expression", because in SymPy, I guess, objects are not typed.
Another example, again: how would you multiply symmetric functions in SymPy? Or
Maple or Mathematica, if you prefer.
> Because having the expression in the form of the 4 basic classes (Add, Mul,
> Pow, Integer), everything else can be easily inferred from this.
I should add: it is indeed useful to have such a representation, too. (called:
ExpressionTree). Many things are easier to do with ExpressionTrees. But even
better is to have both, as we do in Axiom/Aldor.
Martin
- [Axiom-developer] CAS for the masses, daly, 2007/03/28
- Re: [Axiom-developer] CAS for the masses, Gabriel Dos Reis, 2007/03/28
- Re: [Axiom-developer] CAS for the masses, Ondrej Certik, 2007/03/28
- Re: [Axiom-developer] CAS for the masses, Ralf Hemmecke, 2007/03/28
- [Axiom-developer] Re: Advantage of Types and different representations,
Martin Rubey <=
- Re: [Axiom-developer] CAS for the masses, Gabriel Dos Reis, 2007/03/28
- Re: [Axiom-developer] CAS for the masses, Ondrej Certik, 2007/03/28
- RE: [Axiom-developer] CAS for the masses, Bill Page, 2007/03/29
- Re: [Axiom-developer] CAS for the masses, Ondrej Certik, 2007/03/29
- RE: [Axiom-developer] CAS for the masses, Bill Page, 2007/03/29
- Re: [Axiom-developer] CAS for the masses, Ralf Hemmecke, 2007/03/29
- Re: [Axiom-developer] CAS for the masses, Bill Page, 2007/03/30
- Re: [Axiom-developer] CAS for the masses, Ralf Hemmecke, 2007/03/30
- Re: [Axiom-developer] CAS for the masses, Martin Rubey, 2007/03/30
- Re: [Axiom-developer] CAS for the masses, Waldek Hebisch, 2007/03/30