Changes
http://wiki.axiom-developer.org/382DivideIfCanUnivariatePolynomialDivisionPackageAlgorithm/diff
--
Even though I used the word "coerce" in my previous mail, the actual sequence
of function searches was using the equivalent of a polynomial lift (that is,
apply a function 'A->B' (any function perhaps) to the coefficient to view a
polynomial over 'A' as a polynomial over 'B'; in this case this lift comes from
'UPOLYC2' with signature '((ZMOD 9 -> INT),UP(x,ZMOD 9)) -> UP(x,INT)'. Such
lifting is common in the interpreter---in fact, the interpreter tried and
applied a number of them before this last one; for example: '((POLY ZMOD 9 ->
ZMOD 9),UP(x,POLY ZMOD 9)) -> UP(x,ZMOD 9)'. I don't know if the documentation
explicitly forbids using 'convert' as the first argument (it may even
explicitly allow 'convert', 'retract', and 'coerce'). I believe it only says
there should be no *automatic* "coercion" using 'convert' and this rule is
obeyed in these examples and the one below.
\begin{axiom}
c:ZMOD(9):=4
)set mess bot on
d:INT:= c+7
e:=c+7
)set mess bot off
\end{axiom}
Note that it said there is no modemap '+' from '(ZMOD(9), INT)->INT'. Instead
it coerced '7' from 'INT' to 'ZMOD(9)', obtained a result in ZMOD(9) and then
'convert' the result to 'INT' only because 'd' was declared to be 'INT'.
Compare this with the type of 'e'.
Something strange happened though. When I first ran the above example (without
the line for 'e'), I did NOT get an answer for 'd' during preview. The
Interpreter stopped with an error message (no modemap). Now I could not
reproduce this even after cancelling the reply, restarted loading the page,
switching browser, doing )clear all, etc. Should one expect the result of 'd'
or 'e' to be 11?
--
forwarded from http://wiki.axiom-developer.org/[EMAIL PROTECTED]
