[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] about Expression Integer

From: Bill Page
Subject: RE: [Axiom-developer] about Expression Integer
Date: Sun, 19 Feb 2006 12:06:05 -0500

On February 18, 2006 2:37 PM Ralf Hemmecke wrote:
> >> 1/ Can I (or cannot) remain Expressions as 
> >>
> >> x+1/(y+1)             
> >> y+1/(x+1)             
> >>
> >> and do not have a single denominator.
> Unfortunately, I have no idea, how to do this. :-(

It is obvious, isn't it, that to do this is Axiom you *must*
find a domain of which this expression can be a member?
> But, I'd like to warn you. Don't follow Bill's suggestion.

I think it is strange how confident both of us are in the
opposite opinion. :)

I don't think you have shown any flaw in my suggestion. It seems
to me to be very reasonable solution to the problem originally
posed by Francois. In fact this same approach is used on other
parts of Axiom.

Perhaps your concern arises because you have not worked out
completely how Axiom uses the concept of domain. I know that
you understand this idea in some depth because of your background
with Aldor. As a programmer and a long term user of Maple, I
had, perhaps, a similar background, but it has taken me more
than two year of working with Axiom to really understand (at
least I think I now understand :) how it is applied to mathematics.

> > There are however more complex domains which do include
> > expressions of the same form as you wrote above. The interpreter
> > is not able to find these automatically, but you can help by
> > specifying more exactly what you want. In the compiler you must
> > always provide this additional information. For example:
> > 
> > (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (2)  x + -----
> >             y + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> > In this case your expression is a member of the specified domain
> > and no conversion is necessary, but notice that the 2nd term is 
> > a monomial of degree 0 since this domain has coefficients that
> > can be expressions. You might consider this result ambiguous
> > since the entire expression could be consider a term degree 0,
> > but apparently the domain DMP attempts construct a polynomial of
> > highest degree? To know for sure we would probably have to consult
> > the source code for DMP.
> Right. In order to know what will happen, a user would have to
> consult the source code. That's completely unsatisfactory.

The solution is *not* to abandon something that is central to
the design of Axiom but rather to write proper, correct and
complete documentation. In particular it is important to realize
that the object that is called a DMP in Axiom is almost, but
not quite that same thing as what a mathematician would call a
polynomial. It is actually something a little more general. It
makes a explicit distinction between the underlying coefficient
domain and the polynomial domain itself. This is something that
one would not (normally) do in mathematics.

There is no problem with this when you think in terms of
programming, but it does sometimes cause some cognitive
dissonance when thinking in terms of the mathematics. In fact
this is quite normal when using other computer algebra systems
as well as Axiom and I think Axiom represents a better
compromise between programming and mathematics than most.

> Even more, I think the interpreter should forbid to construct
> things like DistributedMultivariatePolynomial([x,y],
> Expression Integer).

No! I think this would be very much against the overall design
of Axiom. We must be able to construct domains in this manner.
That is where a great deal of power lies in Axiom that is not
available in other computer algebra systems.

> Take, for example (axiom--main--1--patch-47)
> P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> a: P := x
> degree a
> Are you sure that you expected
> [1,0]
>        Type: DirectProduct(2,NonNegativeInteger)
> as output, given the fact that x is an element of the coefficient
> domain?

Yes. This makes perfectly good sense to me. 'x' is also a polynomial
variable. Since DMP is the highest level domain constructor, I would
expect it to interpret 'x' as being in the polynomial domain first
and only if forced treat is as being in the underlying coefficient

What about? (Notice that Axiom makes you work harder to say something
like this.)

  b := monomial(x,[0,0]::DirectProduct(2,NNI))$P

Can you explain this result?

(23) -> degree b

   (23)  [0,0]
   Type: DirectProduct(2,NonNegativeInteger)

(24) -> b+x

   (24)  x + x
    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> Now, it is totally clear that
> degree(a/x)
> also gives
> [1,0]
>        Type: DirectProduct(2,NonNegativeInteger)
> since
> a/x
>          1
>     (5)  - x
>          x
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> yields also a completely correct output. ;-) However, I guess, most
> people find this confusing.

I think this is only confusing if you try to think of this
expression out of context, that is, without thinking about the
structure of the domain to which is belongs. Everything that
Axiom is doing here is well-defined and can be useful in the right
context (such as the expansion of trigonometric functions in
Francois' original problem).

It seems to me that Axiom's documentation is deficient because it
does not sufficiently emphasis in what way Axiom differs from other
computer algebra systems. And it does not say nearly enough about
how the fundamental ideas in Axiom such as 'domain' related to the
mathematics that it intends to represent. But I think this is
understandable because what Axiom does in some ways is quite
radical. To really appreciate it takes some time and a lot of work.

The developers of Axiom where quite well aware of this, I think.
That is the reason for the proposal for B# (B natural). Axiom's
current interpreter exposes to much of these details to the first
time user. They need a more gentle introduction to these ideas.
But eventually in order to program in Axiom, it is essential that
they gain a full appreciation of the object-oriented design

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]