[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] [DistributedMultivariatePolynomial]
From: |
wyscc |
Subject: |
[Axiom-developer] [DistributedMultivariatePolynomial] |
Date: |
Mon, 27 Feb 2006 21:00:32 -0600 |
Changes http://wiki.axiom-developer.org/DistributedMultivariatePolynomial/diff
--
>The evaluation of 1/x x in 'DistributedMultivariatePolynomial([x],Polynomial
>Integer)' is equivalent to 1 but it is not equivalent to 1 in
>'DistributedMultivariatePolynomial([x],Fraction Polynomial Integer)'. It is
>precisely because the coefficient ring is different. This is completely
>acceptable to me.
I am sorry, Bill. This is not acceptable. $R[x]$ is a subring of $Q(R)[x]$
where $Q(R)$ is the quotient field of $R$. 1/x is in neither of these
polynomial rings, (((No matter what $R$ is!))). This is a FACT of mathematics,
the meaning of what an indeterminate x over a ring or field is. 1/x ONLY lives
in $Q(R[x]) = Q(Q(R)[x]$, where $(1/x)\times x = 1$.
If you want Axiom to be "The Scientific Computation System", you can't have it
any other way.
The only meaningful justification that
>1/x x in 'DistributedMultivariatePolynomial([x],Polynomial Integer)' is
>equivalent to 1
is to view 1/x x in its quotient field, perform the operation, gets 1 and then
retract it back to the ring. (This is mathematics, and independent of how the
Interpreter does it).
There is NO justification for
>but it is not equivalent to 1 in
>'DistributedMultivariatePolynomial([x],Fraction Polynomial Integer)'
where the only explanation you can give is to view 1/x in the ground ring
(which is totally wrong mathematically)!
Contrary to Tim's view, I don't think we can both be "right". You are wrong,
admit it, and let's move on.
William
PS I would challenge you to show me any other CAS that would interpret 1/x x to
be anything other than 1 (if you can, then that CAS is also wrong!)
PPS: This error is entirely due to the Interpreter and has nothing to do with
particular implementations of polynomial rings like DMP, UP, SUP, you name it.
When different polynomial implementations are used and we get different
coercion sequences leading to different results on such a simple computation,
it is time to get rid of automatic coercion in the Interpreter. There is simply
no coercion theory to guarantees that one can get from point A to point B in a
computation (A = $(1/x)\times x$ and B = 1) independent of domains and the path
of coercions. We need confluence in such rewriting.
Axiom would be so much easier to learn if it weren't for the automatic
coercions in the Interpreter. One benefit would be: if you test code in the
Interpreter successfully, you can immediately move it to the compiler without
change.
--
forwarded from http://wiki.axiom-developer.org/address@hidden