RE: [Axiom-developer] about Expression Integer

[Bill Page]

On February 20, 2006 4:53 AM Francois Maltey wrote:

> ... 
> For students and I a lot of problems are about :
> << You think that 2 objects are identical if their writing 
> are identical. >>
> 
> The 2 way to read the x is logical when we think as axiom, 
> but is a trap for students who use computer algebra for
> solving a mathematical exercise.

I agree that Axiom could be improved by using a more rich
output format for complex constructions. Of course when Axiom
was originally designed the computer output devices where not
so advanced - it was exciting then just to print an integral
sign on an ASCII terminal, however bad it looked. Now we can
produce much richer output directly from LaTeX on the computer
screen that would be less ambiguous and easier to read.

But really I do not expect a complicated domain such:

  DMP([x,y],EXPR INT)

to be of much use to beginning students. Usually either 'POLY INT'
or 'EXPR INT' are enough. I proposed it to you because you were
interested in re-programming the package TRMANIP to perform
better trigonometric expansions. In that case it would be used
only internally in the coding of these expansions.

> Bill Page propose :
> > But really it is very simple and easy to predict. The problem
> > is that most people focus is on the wrong thing. This is
> > especially natural if they have previous experience with
> > other computer algebra systems.
> 
> But almost all my student use derive or maple or a TI-9? for
> little computation, and during their mathematical studies they
> don't learn object programming. So it's impossible to say : 
> << learn axiom from the emptyset. >>
>

I don't think it is necessary to learn object-oriented
programming in order to *use* Axiom - at least, I agree that
it should not be necessary. Axiom was designed and implemented
most of the ideas about categories and domains before computer
science even considered the concept. Axiom actually implemented
some fairly common abstract mathematical ideas about "domains"
which you still see in the formal definitions of mathematical
objects like moniods, groups etc. And it extended these ideas in
a logical way that in the end is similar (not identical) to
modern ideas about object-oriented programming. But now perhaps,
the computer science student has an earlier introduction to
these sort of abstractions than the mathematics student.

A side comment: It often seems to me that both theoretical
physics and computer science take mathematics "more seriously"
than the mathematicians themselves. You can see this to the
extent to which so called "pure mathematics" is actually
*applied* in these subjects. In promoting computer algebra to
mathematicians we are sometimes in the odd situation of trying
to sell these "mathematical" ideas back to their originators. :)
 
> I like mupad because easy computation was easy to type, 
> but difficult idea can be done with clever idea about Domains.
> I hope that axiom should have the same point of view. 
>

Unfortunately, I have to agree that Axiom does not do a good
job of this. The designers of Axiom were aware of this problem
and that is one reason why there was a proposed to develop a
new interpreter for Axiom called B# (B natural) which would
provide an initially much more intuitive user interface for
new users. Unfortunately the research funding for Axiom ran
out, before these ideas could be realized. I think it would
be great if someday the open source Axiom project could
resurrect this work.
 
> Martin Rubey wrote: 
> > I could imagine that some innocent looking computation
> > would not be correct in the situation above. 
> 
> As Martin I already imagine this error :
> 
> P := DMP([x,y], EXPR INT) 
> a :P := x 
> b := a/x 
> 
> differentiate(b,x)                    -- 1/x

(4) -> differentiate(b,x)

        1
   (4)  -
        x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

I think this result should be classed a bug. The 'differentiate'
operation apparently makes some incorrect assumptions about the
coefficient domain. I think the result should be the same as:

(5) -> differentiate(b::EXPR INT,x)::P

   (5)  0
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

So we should create a bug report in

  http://wiki.axiom-developer.org/IssueTracker


> differentiate(b+x,x)@EXPR INT         -- 0
>

For this I get:

(6) -> differentiate(b+x,x)@EXPR INT

   (6)  1
   Type: Expression Integer
 
which seems correct to me.

> I find it's a wonderful idea ((***)) to have an error or a 
> warning during b := a/x. It's really possible ?
> 

Yes. I think Martin's proposed code could be easily changed
to give a warning, but in some cases (e.g. in the case of
using this type of construction inside the TRMANIP package)
I think this warning could cause some confusion. So I think
it would be better do in the Axiom interpret code rather than
in the definition of the domain itself.
 
> Bill, I don't want to change all the axiom language ;-)
> it's the _only_ trap I see in the interpreter.
>

I am sure that there are other traps... ;-) I am not against
changing the "axiom language", for example I mentioned B# above,
but do I think we have to be very careful when we consider changes
to Axiom's mathematical library. The library is large, complex,
poorly documented, and based on some theories that are barely more
than research ideas. Even small changes might have large unexpected
consequences. But still, I would claim that Axiom is superior to
most other computer algebra systems in this regard - that is how
bad the situation is with some of these other systems!
 
> The other computation are logical for students in mathematics. ;-)
> And if a student can understand the coefficient function, he 
> can understand why it's a silly computation to type
> monomial(x, [0,0]...)
> Bill you think it's must remain possible, why not. 
> 

What might seem silly in some situations might be sensible
in other situations.

Regards,
Bill Page.