[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiomdeveloper] [#191 exquo and therefore gcd cannot handle UP(x, EXPR
From: 
Bill Page 
Subject: 
[Axiomdeveloper] [#191 exquo and therefore gcd cannot handle UP(x, EXPR INT)] 
Date: 
Tue, 12 Jul 2005 23:47:17 0500 
Changes
http://page.axiomdeveloper.org/zope/mathaction/191ExquoAndThereforeGcdCannotHandleUPXEXPRINT/diff

??changed:
simplify q
simplify(q::EXPR INT)
removed:

From wyscc Mon Jul 11 18:18:25 0500 2005
From: wyscc
Date: Mon, 11 Jul 2005 18:18:25 0500
Subject: plausible explanation
MessageID: <address@hidden>

The problem is

\begin{axiom}
r := simplify (x2^a)*(x+2^a)
gcd(p,r)
\end{axiom}
ends up in EXPR INT, not 'UP(x,EXPR INT)' which is entirely reasonable. But
then the 'x' in 'r' is no longer the same 'x' in p and hence the 'gcd(p,r)' is
1.

I don't think anything should be fixed. Users are responsible when they mix
variables in nested polynomial domains. Check out the code for
triangularSystems where careful pushing and pulling of these variables are done.

From wyscc Mon Jul 11 18:54:08 0500 2005
From: wyscc
[30 more lines...]
??changed:
So Mathaction should give a warning that in using the reply box (instead of
directly editing the page), a new session of Axiom is initiated.

My analysis of Mon, 11 Jul 2005 18:18:25 0500 was not supported (but might
still be the explanation). When done in step by step, Axiom does coerce 'r'
correctly to what a normal user would expect. So the question is: why would it
make a difference when everything is put on one line?

My guess is that when the command is in one line, the arguments are evaluated
first (supported by the sequence displayed with ')set mess bot on' ) and the
coercion is done without the benefit of knowledge that 'gcd' is to be involved.
Without this, the coercion from 'EXPR INT' to 'UP(x,EXPR INT)' is one from the
coefficient to the univariate polynomial ring. Then the gcd is performed
without further problem and yields '1'. In the step by step case, even though
in 'gcd(p,r)', 'r' has type 'EXPR INT', the Interpreter is looking for a map
'gcd' and not finding one, will now coerce 'r' to 'UP(x, EXPR INT)' and this
time, the coercion was done in a different way. Unfortunately, ')set mess bot
on' does not help here.



From BillPage Mon Jul 11 21:24:05 0500 2005
From: Bill Page
Date: Mon, 11 Jul 2005 21:24:05 0500
Subject: MathAction playing tricks
MessageID: <address@hidden>

William Sit wrote:

> When I edit, the entire page is rerendered and hence the answer
> is the correct answer (not 1), but when I reply, a new instance
> of Axiom is started.
[73 more lines...]
When done in step by step, Axiom does coerce 'r' correctly to what a normal
user would expect. So the question is: why would it make a difference when
everything is put on one line?
My guess is that when the command is in one line, the arguments are evaluated
first (supported by the sequence displayed with ')set mess bot on' ) and the
coercion is done without the benefit of knowledge that 'gcd' is to be involved.
Without this, the coercion from 'EXPR INT' to 'UP(x,EXPR INT)' is one from the
coefficient to the univariate polynomial ring. Then the gcd is performed without
further problem and yields '1'. In the step by step case, even though in
'gcd(p,r)', 'r' has type 'EXPR INT', the Interpreter is looking for a map 'gcd'
and not finding one, will now coerce 'r' to 'UP(x, EXPR INT)' and this time,
the coercion was done in a different way. Unfortunately, ')set mess bot on'
does not help here.

forwarded from http://page.axiomdeveloper.org/zope/mathaction/address@hidden