help links subscribe changes refresh edit

	IssueTracker
#118 Quaternion restriction ←	↑	→ #12 radicalSolve fails to find all roots ?

#119 solve returns wrong answers and multiple answers to same trig problem

Edit detail for #119 solve returns wrong answers and multiple answers to same trig problem revision 1 of 2

	1 2
Editor: Time: 2007/11/17 21:54:03 GMT-8
Note:

changed:
-
Only one of these answers is correct:
\begin{axiom}
eq1:=%pi/2-asin(n/2)=asin(n)
s:=solve(eq1,n)
-- repeating is ok
s:=solve(eq1,n)
subst(eq1,s.1)::Equation Expression Float
subst(eq1,s.2)::Equation Expression Float
\end{axiom}

We should expect the same result from:
\begin{axiom}
)clear all
eq1:=%pi/2-asin(n/2)=asin(n)
s:=solve(eq1,n)
-- repeating is not ok!
s:=solve(eq1,n)
subst(eq1,s.1)::Equation Expression Float
subst(eq1,s.2)::Equation Expression Float
subst(eq1,s.3)::Equation Expression Float
subst(eq1,s.4)::Equation Expression Float
\end{axiom}

But now there are 4 results for the same equation!

From BillPage Wed Mar 9 23:14:48 -0600 2005
From: Bill Page
Date: Wed, 09 Mar 2005 23:14:48 -0600
Subject: Why Complex Float?
Message-ID: <20050309231448-0600@page.axiom-developer.org>

Why do I need to use Complex Float in order to evaluate the
numeric value of these expression? Just Float will not work
\begin{axiom}
asin(1/2)::Float
asin(1/2)::Complex Float
\end{axiom}

<pre>From: wyscc, Thur, 10 Mar 2005 08:16:00</pre>

Of course you don't, from a mathematical view point, and the problem is apparently the Interpreter needs help. If you put the argument into <code>Float</code> or the expression into <code>Expression Float</code>, Axiom will oblige.
\begin{axiom}
asin(1/2::Float)
asin(1/2)::Expression Float
\end{axiom}
But in fact, even coercion to <code>Complex Float</code> won't always work.
\begin{axiom}
asin(%i/2)
asin(%i/2)::Complex Float
\end{axiom}
There is no modemap from <code>Expression Integer</code> to <code>Complex Float</code> (Use hyperdoc <code>Browse, Selectable</code> to search, with wild character in the name field).  This is reasonable since it is not possible in general to evaluate numerically a symbolic expression. I believe the Interpreter actually tries this:
\begin{axiom}
asin(1/2)$Float
asin(1/2)$(Complex Float)
\end{axiom}
which succeed in both cases because <code>asin</code> has modemaps in those domains. Exactly why it was able to change a  non-existing coercion in one case but not the other is unclear, but this seems to be because the Interpreter code is not as categorical as the compiler code and these ``smart'' coercions may be done case by case. But even this reasoning has problem:

\begin{axiom}
asin(%i/2::Complex Float)  -- easiest
asin(%i/2)::Expression Complex Float::Complex Float -- harder
asin(%i/2)$(Complex Float)  -- doesn't work
\end{axiom}


From BillPage Thu Mar 10 09:50:00 -0600 2005
From: Bill Page
Date: Thu, 10 Mar 2005 09:50:00 -0600
Subject: Ah, so subtle are the Axiom types!
Message-ID: <20050310095000-0600@page.axiom-developer.org>

William,

Thank you for the explanation. Now I "get it". The kind of
coercion that I really wanted to do was like this::

  sin(1)::Expression Float

This is taking something from Expression Integer to Expression Float
which always works even for:
\begin{axiom}
  sin(x)::Expression Float
\end{axiom}

But when x converts to Float then the whole expression can be
displayed like Float (even though it remains Expression Float!).
In the coercion we are just changing the 'ground type' of the
Expression. In fact it can be converted to Float by the function
'ground'.
\begin{axiom}
ground(sin(1)::Expression Float)
\end{axiom}

Or just
\begin{axiom}
sin(1)::Expression Float::Float
\end{axiom}

Perhaps a function 'groundIfCan' would be nice :)

But in general the interpreter should not be expected know
that such a chain of coercions is possible. Right

Neat and very general. Its the same for all trig, exp, log,
etc. functions.

So now I also agree that the coercion to Complex Float does
**not** make sense. Notice that the following error messages
should be the same:
\begin{axiom}
log(10.0*q)::Float
log(10.0*q)::Complex Integer
log(10.0*q)::Complex Float
\end{axiom}

But the Complex Float domain is doing something extra.

If this is because of the interpreter then I think it is
trying too hard and as a result it makes it difficult to
explain this behaviour to the novice user. In this case I
would prefer the interpretation to be more *categorical*
and consistent so that we can explain this subtly from the
very beginning.

Bill Page.


From BillPage Thu Mar 10 22:32:58 -0600 2005
From: Bill Page
Date: Thu, 10 Mar 2005 22:32:58 -0600
Subject: property change
Message-ID: <20050310223258-0600@page.axiom-developer.org>

<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.)

Only one of these answers is correct:

fricas

eq1:=%pi/2-asin(n/2)=asin(n)

$\label{eq1}{{-{2 \ {\arcsin \left({n \over 2}\right)}}+ \pi}\over 2}={\arcsin \left({n}\right)}$

(1)

Type: Equation(Expression(Integer))

fricas

s:=solve(eq1,n)

$\label{eq2}\left[{n = -{2 \over{\sqrt{5}}}}, \:{n ={2 \over{\sqrt{5}}}}\right]$

(2)

Type: List(Equation(Expression(Integer)))

fricas

-- repeating is ok
s:=solve(eq1,n)

$\label{eq3}\left[{n = -{2 \over{\sqrt{5}}}}, \:{n ={2 \over{\sqrt{5}}}}\right]$

(3)

Type: List(Equation(Expression(Integer)))

fricas

subst(eq1,s.1)::Equation Expression Float

$\label{eq4}{2.0344439357_957027354}= -{1.1071487177_94090503}$

(4)

Type: Equation(Expression(Float))

fricas

subst(eq1,s.2)::Equation Expression Float

$\label{eq5}{1.1071487177_94090503}={1.1071487177_94090503}$

(5)

Type: Equation(Expression(Float))

We should expect the same result from:

fricas

)clear all

   All user variables and function definitions have been cleared.
eq1:=%pi/2-asin(n/2)=asin(n)

$\label{eq6}{{-{2 \ {\arcsin \left({n \over 2}\right)}}+ \pi}\over 2}={\arcsin \left({n}\right)}$

(6)

Type: Equation(Expression(Integer))

fricas

s:=solve(eq1,n)

$\label{eq7}\left[{n = -{2 \over{\sqrt{5}}}}, \:{n ={2 \over{\sqrt{5}}}}\right]$

(7)

Type: List(Equation(Expression(Integer)))

fricas

-- repeating is not ok!
s:=solve(eq1,n)

$\label{eq8}\begin{array}{@{}l} \displaystyle \left[{ \begin{array}{@{}l} \displaystyle n = -{{\sqrt{{{{\left(-{8 \ {{{e}^{\pi \over{\sqrt{- 1}}}}^{2}}}+{{34}\ {{e}^{\pi \over{\sqrt{- 1}}}}}- 8 \right)}\ {\sqrt{{{{1 6}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{6}}}-{{32}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{5}}}-{{16}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{4}}}+{{64}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{3}}}-{{16}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{2}}}-{{32}\ {{e}^{\pi \over{\sqrt{- 1}}}}}+{16}}\over{{{1 6}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{5}}}-{{136}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{4}}}+{{321}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{3}}}-{{1 36}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{2}}}+{{16}\ {{e}^{\pi \over{\sqrt{- 1}}}}}}}}}+{{20}\ {{{e}^{\pi \over{\sqrt{- 1}}}}^{2}}}-{{40}\ {{e}^{\pi \over{\sqrt{- 1}}}}}+{20}}\over{{4 \ {{{e}^{\pi \over{\sqrt{- 1}}}}^{2}}}-{{17}\ {{e}^{\pi \over{\sqrt{- 1}}}}}+ 4}}}\over 2}$

(8)

Type: List(Equation(Expression(Integer)))

fricas

subst(eq1,s.1)::Equation Expression Float

$\label{eq9}{2.0344439357_957027354}= -{1.1071487177_94090503}$

(9)

Type: Equation(Expression(Float))

fricas

subst(eq1,s.2)::Equation Expression Float

$\label{eq10}{1.1071487177_94090503}={1.1071487177_94090503}$

(10)

Type: Equation(Expression(Float))

fricas

subst(eq1,s.3)::Equation Expression Float

$\label{eq11}{2.0344439357_957027354}= -{1.1071487177_94090503}$

(11)

Type: Equation(Expression(Float))

fricas

subst(eq1,s.4)::Equation Expression Float

$\label{eq12}{1.1071487177_94090503}={1.1071487177_94090503}$

(12)

Type: Equation(Expression(Float))

But now there are 4 results for the same equation!

Why Complex Float? --Bill Page, Wed, 09 Mar 2005 23:14:48 -0600 reply

Why do I need to use Complex Float in order to evaluate the numeric value of these expression? Just Float will not work

fricas

asin(1/2)::Float

   Cannot convert from type Expression(Integer) to Float for value
        1
   asin(-)
        2

asin(1/2)::Complex Float

$\label{eq13}{0.5235987755_9829887307}-{{0.3388131789_0172013563 E - 20}\ i}$

(13)

Type: Complex(Float)

From: wyscc, Thur, 10 Mar 2005 08:16:00

Of course you don't, from a mathematical view point, and the problem is apparently the Interpreter needs help. If you put the argument into Float or the expression into Expression Float, Axiom will oblige.

fricas

asin(1/2::Float)

$\label{eq14}0.5235987755_9829887308$

(14)

Type: Float

fricas

asin(1/2)::Expression Float

$\label{eq15}0.5235987755_9829887308$

(15)

Type: Expression(Float)

But in fact, even coercion to Complex Float won't always work.

fricas

asin(%i/2)

$\label{eq16}\arcsin \left({i \over 2}\right)$

(16)

Type: Expression(Complex(Integer))

fricas

asin(%i/2)::Complex Float

   Cannot convert from type Expression(Complex(Integer)) to Complex(
      Float) for value
        %i
   asin(--)
         2

There is no modemap from Expression Integer to Complex Float (Use hyperdoc Browse, Selectable to search, with wild character in the name field). This is reasonable since it is not possible in general to evaluate numerically a symbolic expression. I believe the Interpreter actually tries this:

fricas

asin(1/2)$Float

$\label{eq17}0.5235987755_9829887308$

(17)

Type: Float

fricas

asin(1/2)$(Complex Float)

$\label{eq18}{0.5235987755_9829887307}-{{0.3388131789_0172013563 E - 20}\ i}$

(18)

Type: Complex(Float)

which succeed in both cases because asin has modemaps in those domains. Exactly why it was able to change a non-existing coercion in one case but not the other is unclear, but this seems to be because the Interpreter code is not as categorical as the compiler code and these ``smart'' coercions may be done case by case. But even this reasoning has problem:

fricas asin(%i/2::Complex Float)

easiest

$\label{eq19}{0.4812118250_5960344749}\ i$

(19)

Type: Complex(Float)

fricas

asin(%i/2)::Expression Complex Float::Complex Float -- harder

$\label{eq20}{0.4812118250_5960344749}\ i$

(20)

Type: Complex(Float)

fricas

asin(%i/2)$(Complex Float)  -- doesn't work

   There are 1 exposed and 6 unexposed library operations named asin 
      having 1 argument(s) but none was determined to be applicable. 
      Use HyperDoc Browse, or issue
                              )display op asin
      to learn more about the available operations. Perhaps 
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named asin 
      with argument type(s) 
                         Fraction(Complex(Integer))

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

Ah, so subtle are the Axiom types! --Bill Page, Thu, 10 Mar 2005 09:50:00 -0600 reply

William,

Thank you for the explanation. Now I "get it". The kind of coercion that I really wanted to do was like this:

  sin(1)::Expression Float

This is taking something from Expression Integer to Expression Float which always works even for:

fricas

sin(x)::Expression Float

$\label{eq21}\sin \left({x}\right)$

(21)

Type: Expression(Float)

But when x converts to Float then the whole expression can be displayed like Float (even though it remains Expression Float!). In the coercion we are just changing the ground type of the Expression. In fact it can be converted to Float by the function ground.

fricas

ground(sin(1)::Expression Float)

$\label{eq22}0.8414709848_0789650665$

(22)

Type: Float

Or just

fricas

sin(1)::Expression Float::Float

$\label{eq23}0.8414709848_0789650665$

(23)

Type: Float

Perhaps a function groundIfCan would be nice :)

But in general the interpreter should not be expected know that such a chain of coercions is possible. Right

Neat and very general. Its the same for all trig, exp, log, etc. functions.

So now I also agree that the coercion to Complex Float does not make sense. Notice that the following error messages should be the same:

fricas

log(10.0*q)::Float

   Cannot convert from type Expression(Float) to Float for value
   log(10.0 q)

log(10.0*q)::Complex Integer

   Cannot convert from type Expression(Float) to Complex(Integer) for 
      value
   log(10.0 q)

log(10.0*q)::Complex Float

   >> Error detected within library code:
   Cannot compute the numerical value of a non-constant expression

But the Complex Float domain is doing something extra.

If this is because of the interpreter then I think it is trying too hard and as a result it makes it difficult to explain this behaviour to the novice user. In this case I would prefer the interpretation to be more categorical and consistent so that we can explain this subtly from the very beginning.

Bill Page.

property change --Bill Page, Thu, 10 Mar 2005 22:32:58 -0600 reply

From: wyscc, Fri, 11 Mar 2005 00:37:00

Perhaps a function groundIfCan would be nice :)

The origin implementation of ground in Expression is from FunctionSpace (according to Hyperdoc) and may give an error if the argument is not from the ground domain. There is a function ground? which does the test. A more common (and indeed more general) function is retractIfCan, which would give "failed" if the retraction cannot be done. There are 8 modemaps for retractIfCan in Expression Float and you can retract to Algebraic Number, Float, Fraction Integer, Fraction Polynomial Float, Integer, Kernel Expression Float, Polynomial Float and Symbol. 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 numeric in the first instance (it should), did not find any modemap from POLY FLOAT -> COMPLEX INT (there are none, which makes sense), but found complexNumeric in the last. In the first one, numeric.o is not loaded because the Interpreter somehow is not instructed to look for numeric. Even after numeric.o is loaded, the situation is the same: the Interpreter stops after locating log: EXPR FLOAT ->EXPR FLOAT. In the last case, the Interpreter loads numeric.o 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).

fricas

numeric(log(10.0*q))

   >> Error detected within library code:
   Can only compute the numerical value of a constant, real-valued Expression

So this treatment agrees with:

fricas

complexNumeric(log(10.0*q))

   >> Error detected within library code:
   Cannot compute the numerical value of a non-constant expression

which has the same output as log(10.0*q)::Complex Float

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

I still have no clue why after a )clear all, the second solve 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 eq1, solve, solve before the )clear all if I was working in some session already. But it occurred consistently if I started with a new Axiom window and followed the script.)