[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiomdeveloper] [#119 solve returns wrong answers and multiple answers
From: 
wyscc 
Subject: 
[Axiomdeveloper] [#119 solve returns wrong answers and multiple answers to same trig problem] 
Date: 
Thu, 10 Mar 2005 23:43:22 0600 
Changes
http://page.axiomdeveloper.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 nonconstant 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.axiomdeveloper.org/zope/mathaction/address@hidden