Only one of these answers is correct: fricas (1) -> eq1:=%pi/2-asin(n/2)=asin(n)
Type: Equation(Expression(Integer))fricas s:=solve(eq1,
Type: List(Equation(Expression(Integer)))fricas -- repeating is ok s:=solve(eq1,
Type: List(Equation(Expression(Integer)))fricas subst(eq1,
Type: Equation(Expression(Float))fricas subst(eq1,
Type: Equation(Expression(Float))We should expect the same result from: fricas )clear all
Type: Equation(Expression(Integer))fricas s:=solve(eq1,
Type: List(Equation(Expression(Integer)))fricas -- repeating is not ok! s:=solve(eq1,
Type: List(Equation(Expression(Integer)))fricas subst(eq1,
Type: Equation(Expression(Float))fricas subst(eq1,
Type: Equation(Expression(Float))fricas subst(eq1, But now there are 4 results for the same equation! fricas asin(1/2)::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 fricas asin(1/2::Float)
Type: Floatfricas asin(1/2)::Expression Float
Type: Expression(Float)But in fact, even coercion to fricas asin(%i/2)
Type: Expression(Complex(Integer))fricas asin(%i/2)::Complex Float There is no modemap from fricas asin(1/2)$Float
Type: Floatfricas asin(1/2)$(Complex Float)
Type: Complex(Float)which succeed in both cases because - fricas
asin(%i/2::Complex Float) - easiest
(16) **Type:**Complex(Float)fricasasin(%i/2)::Expression Complex Float::Complex Float -- harder (17) **Type:**Complex(Float)fricasasin(%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.
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
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 fricas ground(sin(1)::Expression Float)
Type: FloatOr just fricas sin(1)::Expression Float::Float
Type: FloatPerhaps a function 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
fricas log(10.0*q)::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 Bill Page. From: wyscc, Fri, 11 Mar 2005 00:37:00 ```
Perhaps a function
```
The origin implementation of 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 fricas numeric(log(10.0*q)) So this treatment agrees with: fricas complexNumeric(log(10.0*q)) which has the same output as By the way, I think this discussion (the second half, involving conversion to I still have no clue why after a |

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