[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-math] Types in axiom.
From: |
fmaltey |
Subject: |
[Axiom-math] Types in axiom. |
Date: |
08 Oct 2003 19:04:34 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Hello everybody : Tim, Bill, Bertfried...
I try to resume all our mails :
Axiom is an algebra computer, not a tree computer as the 3M.
If axiom want to be sucessfull basic calculus must be easy.
I believe it's too complex to explain all the types before the first
computation of sum, integrate, differentiate, and so.
Tim proposes to make basic calculus over
Expression(Polynomial(Fraction(Integer))).
I like this idea. So I explain types after first examples.
Is it possible that the important functions compute by default in this set ?
MuPAD uses this way : By default an expression in in the field
ExpressionField even if sin(2x) and 2sin(x)cos(x) are diffenrents.
This doesn't work to bad.
---------------------------------------------------------------------------
My detailled reponse :
I also like to use mupad because THIS CAS is typed,
less typed than axiom, but typed.
I don't use maxima and I don't like maple because they aren't typed.
I'm looking for axiom because
it is a strong typed CAD,
and it's more free than mupad.
Of corse, I agree about use of types, and automatic coerce are necessory.
For an use in first-years university syntax might be
as near as possible as other CAS, and texas instrument hand-held computer
So I like to have a syntax as
BP> I think a good definition of 'partfrac' for AXIOM is
BP> partFrac(ex,x) ==
BP> partialFraction(numer ex, (denom ex)::UP(x, FRAC INT))
if the automatic coerce isn't right with partFrac(ex).
BP> The two types x^2 - 1 as something of type: POLY INT versus what appears
BP> as essentially the same thing x^2 - 1 as something of type: UP(x,FRAC INT)
BP> actually occurs very frequently in Axiom.
BP> Unfortunately it is something rather subtle and not
BP> easily explained (rationalized?) to the novice user.
Yes
BP> yet seems essential for new Axiom users to learn this as
BP> soon as possible.
Yes, but it's impossible to explain this during the first lessons.
BF> Maple is going to be sold to students, even high school
BF> students and ingeneers most likely.
BF> Hence the await not mathematics but just an symbolic pocket calculator.
BF> IFF AXIOM wants to be sucessfull on a larger scale (say in the
BF> academic area and partly in teaching) it is a *must* to come with a plain
BF> description of the mathematics behind the types.
TD> However notice that FRAC(INT) does not occur
TD> at the top level of the "type tower". That is, to coerce
TD> UP(x, INT) to UP(x,FRAC INT) you have to "reach into" the type tower
TD> and convert something below the top level type of UP.
Almost every computation are in Z[X1,X2,...,Xn]. Am I right ?
TD> This is a hard problem in general and there is no good theory
TD> I'm aware of that says how to do this in a theoretically correct way.
>There is also the problem that François brings up involving the
>presumptions of those users who have been previously exposed to one
>of the other popular computer algebra systems (e.g. Maple, MuPad,
>Mathematica, Maxima ... ) which do not share Axiom's strongly typed
>metaphor. (I am one of these people. <grin>)
Can I simplify cos(2*x)^2+4*sin(x)^2*cos(x)^2 with axiom ?
How can I explain this easily ?
> Such a users looks for general operations on expressions like
> "expand", "simplify", "combine" etc. and for the most part finds them
> missing from Axiom !
Even if axiom is a ALGEBRA computer
theses functions are useful during almost computation ?
With maple or mupad, if I can't find the good rewrite(....)
function I finish my computation with substitution in the tree.
Axiom uses less sustitutions but this remains sometime usefull.
TD> I think it was Knuth that said "Teaching BASIC to beginning
TD> programmers causes brain damage and the student will never
TD> recover". The 4Ms have created the illusion that you can
TD> freely compute results without worrying about the issues that
TD> Axiom struggles with. I believe that this illusion makes it
TD> very difficult to build ever-larger systems. If you can't
TD> appeal to some theory then the complexity alone will overwhelm
TD> your efforts. Think of the benefits of a strongly typed language
TD> like Java vs a typeless language like BASIC. You can build
TD> programs in BASIC but you eventually hit the wall when the
TD> complexity gets high. Java lets you get further. By analogy
TD> I'm arguing that the 4Ms make simple things simple but complex
TD> things ever harder and that Axiom reverses that. I claim that
TD> Axiom scales and the more theory we develop the better it scales.
I AGREE with you if there is a good algebra for the computation.
But when we don't know the good algebra
1/ We don't uses Axiom
2/ Everybody make a function in lisp
3/ Axiom has some rewrite functions ;
but it might be forbidden to use them !
I prefer the 3/ solution.
But combine or expand function can often be translate in algebra theory
(with space vector or ring, etc. by example with sin(u)^k or sin(k*u))
TD> Of course all of this theory does not help the beginner use Axiom.
TD> At my institute (CAISS at City College of New York) we are planning
TD> to build a series of simple menu-driven front ends for Axiom in a
TD> large variety of courses. The front end hides the complexity because
TD> it only works in a single type (e.g. Expression or POLY(INT)) that
TD> is sufficient for the beginner. Because the operations are all in
TD> one type the issue of type conversion is diminished.
I must programming with my students.
So menu-driven front-end isn't for me the best choice.
But if I can configure axiom to be only Expression or POLY(INT)
powerfull, it's a very good thing.
TD> It is possible to build a series of cover functions that always
TD> work in one type. That will eliminate most of the problems you
TD> are seeing. Expression(Polynomial(Fraction(Integer))) is a type
TD> tower that is probably general enough to do what you want. Of
TD> course the cover functions will have to coerce things back and
TD> forth internally to use the existing functions (such as you did
TD> with partfrac).
I believe I'm lookingthat.
Francois, and excuse my very poor english.