Only one of these answers is correct:

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

(1)

s:=solve(eq1,n)

(2)

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

(3)

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

(4)

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

(5)

We should expect the same result from:

)clear all

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

(6)

s:=solve(eq1,n)

(7)

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

(8)

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

(9)

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

(10)

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

   >> Error detected within library code:
   index out of range

But now there are 4 results for the same equation!

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

asin(1/2)::Float

   Cannot convert the value from type Expression(Integer) to 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.

asin(1/2::Float)

(11)

asin(1/2)::Expression Float

(12)

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

asin(%i/2)

(13)

asin(%i/2)::Complex Float

   Cannot convert the value from type Expression(Complex(Integer)) to 
      Complex(Float) .

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:

asin(1/2)$Float

(14)

asin(1/2)$(Complex Float)

(15)

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

(16)

Type: Complex(Float)

fricas

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

(17)

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.

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:

sin(x)::Expression Float

(18)

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.

ground(sin(1)::Expression Float)

(19)

Or just

sin(1)::Expression Float::Float

(20)

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:

log(10.0*q)::Float

   Cannot convert the value from type Expression(Float) to Float .

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

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:

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

Status: open => fixed somewhere