[Axiom-developer] [#119 solve returns wrong answers and multiple answers to same trig problem]

[wyscc]

Changes 
http://page.axiom-developer.org/zope/mathaction/119SolveReturnsWrongAnswersAndMultipleAnswersToSameTrigProblem/diff
--

??changed:
-
<pre>From: wyscc, Fri, 11 Mar 2005 00:37:00</pre>

>Perhaps a function 'groundIfCan' would be nice :)

The origin implementation of <code>ground</code> in <code>Expression</code> is 
from <code>FunctionSpace</code> (according to Hyperdoc) and may give an error 
if the argument is not from the ground domain. There is a function 
<code>ground?</code> which does the test. A more common (and indeed more 
general) function is <code>retractIfCan</code>, which would give "failed" if 
the retraction cannot be done. There are 8 modemaps for 
<code>retractIfCan</code> in <code>Expression Float</code> and you can retract 
to <code>Algebraic Number, Float, Fraction Integer, Fraction Polynomial Float, 
Integer, Kernel Expression Float, Polynomial Float</code> and 
<code>Symbol</code>.  As far as MathAction goes, I would prefer "failed" rather 
than an error, because an error stops the running of the rest of Axiom script 
block.

>Cannot compute the numerical value of a non-constant expression

>But the Complex Float domain is doing something extra.

The issues here are two: The first two errors are modemap problems. The last 
one is an anticipated error message from algebra code. I suspect that the 
Interpreter did not try to find <code>numeric</code> in the first instance (it 
should), did not find any modemap from <code>POLY FLOAT -> COMPLEX INT</code> 
(there are none, which makes sense), but found <code>complexNumeric</code> in 
the last. In the first one, <code>numeric.o</code> is not loaded because the 
Interpreter somehow is not instructed to look for <code>numeric</code>. Even 
after <code>numeric.o</code> is loaded, the situation is the same: the 
Interpreter stops after locating <code>log: EXPR FLOAT ->EXPR FLOAT</code>. In 
the last case, the Interpreter loads <code> numeric.o</code> if it is not 
there. So it would seem that it is a dependency problem during compiling (which 
presumably provides the database to the Interpreter).

\begin{axiom}
numeric(log(10.0*q))
\end{axiom}

So this treatment agrees with:

\begin{axiom}
complexNumeric(log(10.0*q))
\end{axiom}

which has the same output as <code>log(10.0*q)::Complex Float</code>

By the way, I think this discussion (the second half, involving conversion to 
<code>Float</code>) should be separated into a new page. Perhaps under a title 
like "Numerical Type Conversion".

I still have no clue why after a <code>)clear all</code>, the second 
<code>solve</code> behave the way it did. I have verified that it occurs fairly 
consistently, even in the NAG version. (It occurred even if I had never run the 
first <code>eq1, solve, solve</code> before the <code>)clear all</code> if I 
was working in some session already. But it occurred consistently if I started 
with a new Axiom window and followed the script.)


--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden