[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] about Expression Integer
From: |
Ralf Hemmecke |
Subject: |
Re: [Axiom-developer] about Expression Integer |
Date: |
Mon, 20 Feb 2006 12:28:42 +0100 |
User-agent: |
Thunderbird 1.5 (X11/20051201) |
On 02/19/2006 06:06 PM, Bill Page wrote:
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?
Of course, you are right. I was just saying that I don't know of a
domain which behaves as one would expect. So the next thing I would do
is to write another domain which behaves (and inherits) most things from
Expression Integer but does not group expressions together so that they
are over one denominator.
Maybe one very simple idea would be to write a domain constructor
ExpressionSum(R:OrderedSet): Exports == Implementation where
Exports ==> -- Same as for Expression(R)
Implementation ==> List Expression R
Rep := List Expression R
(x: %) + (y: %): % == per append(rep x, rep y) -- concat lists
-- The other functions have to be implemented accordingly.
-- That will be a lot of work.
coerce(x: %): OutputForm == map(+, [e::OutputForm for e in rep x])
-- Maybe some parens should be added if the expression has
-- a minus sign
I am not sure, however, whether this is the best idea. Unfortunately, I
don't know all the domains of Axiom so well. So maybe my sugestion is
completely irrelevant since something like that is already existing in
Axiom.
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.
Your suggestion does not work if you want to do the following:
x+1/(y+1) + y+1/(x+1)
since
(x+1/(y+1) + y+1/(x+1))$DMP([x,y],EXPR INT)
shows as
y + x + 2
(4) x + y + ----------------
(x + 1)y + x + 1
Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
Of course, ad hoc solutions are not bad as long as one knows what one is
doing, but I somehow don't like the ad hoc method. Either there is a
clever program that guesses correctly what the user wants, or, if this
is not possible, the user should think a bit more and perhaps add more
knowledge to the system. Otherwise Axiom ends up in being like all the
other untyped CAS.
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.
Well, I agree, that you are probably better in applying Axiom to real
world problems, but I hope you agree that if Axiom is not able to do the
things that Francois wants in a clear way, then it would be better (at
least for the future) to add a nice feature to the system instead of
being satisfied that the wish can be fulfilled by an ad-hoc-misuse of
existing domains.
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.
Well, a polynomial in n variables with coefficients in a ring R is an
element of
\Oplus_{e \in N^n} R
where N is the non-negative integers.
If you like, you can attach variable names somewhere. Yes, I also know
that some people define polynomials differently.
And by the way, 1 is a perfect member of DMP([x,y],Integer) also in
Axiom. I know you know that.
(1) -> a: DMP([x,y],Integer) := 1
(1) 1
Type: DistributedMultivariatePolynomial([x,y],Integer)
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)
So, let me interpret a polynomial as above as a function (with finite
support) from the domain of exponents to the domain of coefficients.
(24) clearly has support { [1,0], [0,0] } an is therefore by no means
equal to the polynomial 2x which has support { [1,0] }.
I am not really saying that Axiom is doing something wrong, I am just
warning that the use of DMP([x,y], Expression Integer) can be misleading
for people that don't know how Axiom works internally. Those people
would probably treat (24) as 2x and that interpretation would be wrong.
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.
The context is clearly given. It's the type of (5). Right, I could even
predict, that Axiom should give back that expression. (How could I
otherwise have constructed it?) But the two x's one sees, have different
origins and are therefore not equal.
By the way, you can achieve similar confusing things with Maple.
f:=proc() local x; x end;
a:=f(): b:=f():
evalb(a=b);
That behaviour had once cost me several days to trace down a bug.
Clearly, a looks like x and b looks like x. But they are not equal. I
haven't found this to be documented.
But eventually in order to program in Axiom, it is essential that
they gain a full appreciation of the object-oriented design
philosophy.
I would not really like to call Axiom (or Aldor) object-oriented.
We don't write
a.add(b)
in order to add two numbers.
the function "add" is not attached to the object a. It is rather that a
and b are on equal footing.
Try to program a simple thing as a n-ary polynomial ring in a purely
object-oriented programming language (like for example JAVA even with
generics), then it becomes clear that Axiom has more to offer that the
current trend in programming.
Ralf
- RE: [Axiom-developer] about Expression Integer, (continued)
- RE: [Axiom-developer] about Expression Integer, Bill Page, 2006/02/21
- Re: [Axiom-developer] about Expression Integer, Martin Rubey, 2006/02/22
- RE: [Axiom-developer] about Expression Integer, Bill Page, 2006/02/23
- Re: [Axiom-developer] about Expression Integer, Martin Rubey, 2006/02/22
- RE: [Axiom-developer] about Expression Integer, Bill Page, 2006/02/22
- Re: [Axiom-developer] about Expression Integer, Francois Maltey, 2006/02/22
- Re: [Axiom-developer] about Expression Integer, Martin Rubey, 2006/02/23
- RE: [Axiom-developer] about Expression Integer, Bill Page, 2006/02/23
- Re: [Axiom-developer] about Expression Integer, Ralf Hemmecke, 2006/02/24
- Re: [Axiom-developer] about Expression Integer, William Sit, 2006/02/24
- Re: [Axiom-developer] about Expression Integer,
Ralf Hemmecke <=
- Re: [Axiom-developer] about Expression Integer, Gabriel Dos Reis, 2006/02/20
- Re: [Axiom-developer] about Expression Integer, Ralf Hemmecke, 2006/02/20
- RE: [Axiom-developer] about Expression Integer, Bill Page, 2006/02/20
- Re: [Axiom-developer] about Expression Integer, Gabriel Dos Reis, 2006/02/20
- Re: [Axiom-developer] about Expression Integer, Ralf Hemmecke, 2006/02/21
- Re: [Axiom-developer] about Expression Integer, Gabriel Dos Reis, 2006/02/21
- [Axiom-developer] 1: %, Ralf Hemmecke, 2006/02/21
- [Axiom-developer] Re: 1: %, Gabriel Dos Reis, 2006/02/21
- [Axiom-developer] Re: 1: %, Gabriel Dos Reis, 2006/02/21
- [Axiom-developer] Re: 1: %, Ralf Hemmecke, 2006/02/22