[Axiom-developer] POLY INT =\\= UP(x, INT) (was: [Axiom-math] partialFraction behavi or in Axiom)

[Page, Bill]

Tim, Dylan and François;

This is an interesting discussion and I am glad that we
have *finally* reached the stage of discussions about
Axiom and not just scrambling to get something running
and "out the door"... Yah!

First, there were several emails back and forth that
already covered some of this, but here's my view:

I think a good definition of 'partfrac' for AXIOM is

  partFrac(ex,x) ==
    partialFraction(numer ex, (denom ex)::UP(x, FRAC INT))

Yes, you do have to help AXIOM with some type conversion
information.

But no, I don't think that there is a bug. We have

  POLY INT has EUCDOM  ----------> false
  UP(x, FRAC INT) has EUCDOM ----> true

Apparently POLY INT does not have enough structure.
Specifying x and the FRAC INT domain adds the needed
structure.

I think that this should be/could be so is quite
deeply routed in the design of Axiom and it's type
system. 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,
yet seems essential for new Axiom users to learn this as
soon as possible - that's one reason why I was really
quite impressed by the quality of the NAG Axiom for
Windows tutorial, because it is the first Axiom tutorial
I have seen that tries to address this.

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>) Such a users
looks for general operations on expressions like "expand",
"simplify", "combine" etc. and for the most part finds
them missing from Axiom! To convince some of these users
about the wisdom of Axiom's approach may require some
specially written tutorials and comparisons. And I think
our current discussion is a step toward this.

But inspite of the apparently complexity of Axiom's
current type system (which I agree is largely due it's
poor state of documentation and more than a little ad
hocracy) I think Axiom is still immature with respect to
some of the common operations that beginning Axiom users
(but with previous experience) will expect to see. For
example involving the binomial(p,q) function discussed
by François. There seems to be a whole in Axiom's type
system that does not allow it to deal conveniently with
this case nor with factorials in general. We need to
have clear documentation on the structure of the
algebra and it's type system so that it will be more
clear where this new functionality would be most
efficiently and effacatiously added. As Tim frequently
points out, Axiom is a "long term project"... <sigh>

--------

Let me mention a few simple things of this nature
that surprized me. I have to admit that I really don't
understand some of the Axiom ideas. It is hard to
separate what I don't understand from what I think
might be wrong. But none of these things are serious
problems in the long run. Yet they are examples of the
kind of thing that prevents people from becoming
comfortable with Axiom quickly.

Consider that we can write examples of Axiom types as
follows (assumming no other previous information):

  )clear all

  1        Type: PositiveInteger
  x        Type: Variable x
  x+1      Type: Polynomial Integer
  sin(x)   Type: Expression Integer

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?

And what about the type Axiom associates with something
like:

  sin(1)    Type: Expression Integer

This "expression" contains no variables!

We have

  sqrt(-1)   Type: AlgebraicNumber

Isn't sin(1) also a Number of of some kind? But I
can not write:

  sin(1)::Float

while

  sqrt(-1)::Complex Float

is converted to (or at least represented) as i.
But why not

  sqrt(-1)::Complex Integer

And while I'm complaining ... it seems very strange
that I cannot by default use the name Real like

  POLY Real

although I can write

  POLY Integer

Ok, I know I should write Float instead of Real, but
surely that must be rather irritating to the pure
mathematicians, no?

Now suppose I assign a type to a variable:

  x:Integer

Then I try to use it in:

  x+1

why does Axiom complain that "x is declared as an
Integer but has not been given a value"? What is
different from before? Why doesn't Axiom treat this
as something with

   x+1    Type: Expression Integer

or even

   x+1    Type: Integer Expression Integer

since it "knows" that x is of Type: Integer and 1 is
of Type: PositiveInteger ?

This is exactly the kind of "type" information
that would be useful if we were to try to perform
correct manipulations of expressions like

  binomial(x,y)

I would like to write

  (x,y,z):Matrix Float
  (a,b):Float

and then expect to be able to write

  a*z*x*y*b

to yield

  a*b*z*x*y

If I haven't said what x, y, and z stand for (i.e.
their types), then why does Axiom simply

  z*x*y

to

  x*y*z

?

In all this seem to be a lot of hidden assumptions
and ad hoc behaviour at a fairly basic level. Yes,
I know that Axiom has been used sucessfully for some
fairly advanced mathematical research projects, but
at this fundamental level things seem rather complex
to the new user ...

Systems like Maple and Mathematica have had a lot more
resources in recent years to smooth out some of these
rough edges. With Axiom's recent resurrection from the
ashes, it seems like we have a good opportunity to
address some of these issues.

I am still rather uncertain whether the changes need
to be towards an algebra system that is simpler and
more rigorous but quite possibly less powerful (like
the Aldor project) or whether there should be more
emphasis on tools and techniques that allow one to deal
with the complexity more efficiently and to thereby
successfully build even larger and more complex algebraic
structures (even loops!) in an ongoing manner. I think
clearly that Tim has opted for the latter. Right Tim?

-----

Another subject.

There are a few technical problems with the TeXmacs-
Axiom interface. Most of these can be easily cleaned
up, I think given a little available time. But I think
I disagree with you Dylan about the case of

> factor 15

$$
3 \  5 
\leqno(11)
$$

It seems to me that the space inserted by Axiom is
correct, although in some cases (such as in the case
of single character symbols) it might be replaced with
a "thin" or "medium" space \, \; instead of a "full"
space \ . I think that it is not correct that it currently
disappears in Axiom. (Do you agree?) There is currently
some logic in Sutor's linebreak code (which I encorporated
in the tm_axiom interface) to replace \ with \cdot in
certain cases involving line-broken products. I think
that there is a lot of room to improve and expand on
these typographic issues in the next versions of
tm_axiom.

At first I thought that it might be good if we could get
the TeXmacs folks (Joris) to agree to support the tm_axiom
interface. But now I am thinking more in terms of
recommending that we accept it as a new and more or less
integral part of Axiom and that we should maintain it
along with the other Axiom user interface code. I don't
know if there is really a licensing issue as such, but we
should note that TeXmacs is GPL (and therefore so is the
 revised tm_axiom which was based on their version), not
BSD. (Forget I mentioned this ... )

Sorry for the long email. It's been a long day.

Cheers,
Bill Page.

> -----Original Message-----
> From: Tim Daly [mailto:address@hidden
> Sent: Tuesday, October 07, 2003 2:51 PM
> To: address@hidden
> Cc: address@hidden; address@hidden
> Subject: [Axiom-math] partialFraction behavior in Axiom
> 
> 
> Yes, 
> 
> aa:UP(x,FRAC INT):=2*x^3
> partialFraction(aa,1-x^2)
> 
> also fails in the NAG version. I'm almost certain it is an
> issue of the interpreter walking itself into some corner of
> the type system and failing to find a good resolution. The
> usual answer is to give it more information as you did by
> declaring the types. I'll have to contemplate the "painful"
> output and see where it goes astray.
> 
> However, this is related to the general issue of automatic
> coercions, types, and simplifications. Somebody needs to
> write a complete type graph independent of systems like Axiom
> (which would be a PhD thesis or two). Then we could code it
> up in a less adhoc form. We could answer questions like
> "under what conditions can you coerce from a fraction of
> polynomials over integers to polynomials over fractions
> of integers?" for knarly things like multivariate polynomials.
> What is not apparent on the surface is that some of these
> coercions go thru intermediate types before reaching the
> final output (basically a walk of the type lattice). The
> problem is very hard.
> 
> Tim