[Axiom-developer] RE: opus 1, act 1

[Page, Bill]

Tim,

On Wednesday, October 08, 2003 1:39 AM you wrote:

> ...
> > The distinction between
> >
> >  x^2 - 1
> >
> >as something of type: POLY INT versus what appears
> >as essentially the same thing
> >
> >  x^2 - 1
> >
> >as something of type: UP(x,FRAC INT) actually occurs
> >very frequently in Axiom (e.g. 1::Float, 1.0::Integer).
> >Unfortunately it is something rather subtle and not
> >easily explained (rationalized?) to the novice user,
> 
> Think of it in terms of Java code. You can have two
> classes (POLYINT and UPxFRACINT) that have the same
> print representation but different properties.

Yes and no. I do not think fondly of the Java programming
language. Pardon my opinions, but it seems to me that
Java is largely a failed experiment in portable interpreter/
compiler design that was too much hyped by the corporate
establishment (first SUN and then later others). For the
most part the promises of code reusability and portability
have yet to be attained.

Now that Maple version 9 has been commercially released,
I think I can safely mention that I have been involved in
about 6 months of beta testing of a new graphical user
interface for Maple written entirely in Java "for portability".
The experience was frustrating and the results largely
unsatisfactory (in my opinion). But it has been shipped to
customers along with the older "classical" interface which
was written in C. At least they still have that option for
now.

I like Java in small quantities, e.g. embedded as simple
scripts inside web pages. But for hacking, give me Perl
and for a better approach give me Python (more Lisp-like).
Dropping Java was one of the good things that Microsoft
actually did. Sorry. It's just an "issue" for me.

> 
> I suppose that POLY(INT) is similar to UP(x,INT) since
> the coefficients are integers. There is a way to coerce
> INTs to FRAC(INT)s (the denominator becomes 1). However
> notice that FRAC(INT) does not occur at the top level of
> the "type tower". That is, to coerce UP(x, INT) to
> UP(x,FRAC INT) you have to "reach into" the type tower
> and convert something below the top level type of UP.
> This is a hard problem in general and there is no good
> theory I'm aware of that says how to do this in a
> theoretically correct way.

But there is something else here - specifying the variable(s)
in the polynomial. Without doing that we can not distinguish
between

  a x + a^2

and

  x a + x^2

So POLY INT and UP(x,INT) are clearly different. It is
tempting to think of this a purely a "syntactic" type
difference but I think it becomes a matter of semantics
in AXIOM.

> ... 
> I think it was Knuth that said "Teaching BASIC to
> beginning programmers causes brain damage and the
> student will never recover".

Indeed! "Re-learning" is often more difficult that "learning".

> The 4Ms have created the illusion that you can freely
> compute results without worrying about the issues that
> Axiom struggles with.

I think will have to admit that so far it is a pretty
convincing "illusion"! I continue to be amazed at what
is possible with "modern" computer algebra systems -
and also what remains unreasonably difficult...

> I believe that this illusion makes it very difficult to
> build ever-larger systems. If you can't appeal to some
> theory then the complexity alone will overwhelm your
> efforts. Think of the benefits of a strongly typed language
> like Java vs a typeless language like BASIC. You can build 
> programs in BASIC but you eventually hit the wall when the 
> complexity gets high. Java lets you get further.

Oh, oh. The Java example again ...

> By analogy I'm arguing that the 4Ms make simple things
> simple but complex things ever harder and that Axiom
> reverses that. I claim that Axiom scales and the more
> theory we develop the better it scales.
>

I don't know. Some simple things are still unreasonably
hard in Maple and other similar systems. And getting
started in Axiom is really rather simple, no? I am
optimistic that a more complete, logical and well
documented type system for AXIOM could go a long way
towards making at least the same set of simple things
simple in Axiom as well.
 
> Of course all of this theory does not help the beginner
> use Axiom. At my institute (CAISS at City College of New
> York) we are planning to build a series of simple
> menu-driven front ends for Axiom in a large variety of
> courses.

I am very sceptical of this. Both Mathematica and Maple
(for example see Maplets) have tried this. It does seem
to be of interest in the "teaching circles" but my
interest in it for applications in theoretical physics
is zero.

> The front end hides the complexity because it only
> works in a single type (e.g. Expression or POLY(INT)) that
> is sufficient for the beginner. Because the operations are
> all in one type the issue of type conversion is diminished.

Isn't that like "cutting off AXIOM's nose to suit it's
face" ?? <grin>

> 
> It is possible to build a series of cover functions that
> always work in one type. That will eliminate most of the
> problems you are seeing. Expression
>    Polynomial(Fraction(Integer))
> is a type tower that is probably general enough to do what
> you want. Of course the cover functions will have to coerce
> things back and forth internally to use the existing
> functions (such as you did with partfrac).

Maybe. Perhaps I will try to write a few more like this
and see if it really does provide a more "4M" type of
user layer.

> 
> >Clearly Axiom is trying to choose types that are somehow
> >"smallest" or most conservative. Surely UP(x,PI) is
> >smaller than POLY INT. No? How about (sin x)::EXPR PI.
> >Why is POLY PI an invalid type?
> 
> POLY takes an argument which is a RING.

Yes, of course you are right. But there is still the
issue of specifying the polynomial variables. It seems to
me that AXIOM could choose UP(x ...), MPOLY([x,y, ... ),
or DMP([x,y, ... ) instead of POLY. This might help some
automatic coercions.

> ... 
> So when you try to construct POLY(PI) Axiom checks the
> category of PI to see if is a Ring. It isn't (it lacks
> inverses). So Axiom will not let you construct an incorrect
> type. The same mechanism keeps you from constructing
> Polynomials of files, or matricies of streams. Files
> don't have the properties necessary to be a Ring and
> Polynomials assume their coefficients are Rings. When
> you operate on Polynomials the operations for the
> coefficients (e.g. subtracting) are done by looking up
> the operation "in the coefficient domain".

Yes. The discussion of Files and Polynomials in the
same breath is probably quite a mental stretch for
most beginning AXIOM users (I am now used to this ...)
And the example seems a bit contrived, but I get your
point.

Cheers,
Bill Page.