#76 oa solve() setting result-type fails

[James]

I'm new to open-axiom, but this looks like a bug to me, printing a
floating-point result with "solve()". This is on Ubuntu 8.10, with an older
Athlon machine, compiled with gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2 and using
SBCL 1.0.28.

$ open-axiom
OpenAxiom: The Open Scientific Computation Platform
Version: OpenAxiom 1.3.0
Built on Sunday October 4, 2009 at 11:52:38

xt==(r*(100-s))/(r-s)
xe==cos((%pi/180)*bt)*100*d*( 100^2*(sin((%pi/180)*bt))^2 + d^2*(cos((%pi/180)*bt))^2 )^(-1/2)
bt==(180/%pi)*atan((s*(r-d))/((100-s)*r))

d:=48
r:=rootOf((r-d)^2+(100-s)^2-(r-s)^2,r)

I've noticed that entry is order-dependent when there are immediate
assignments with ":=". Clearing properties of "r" with ")clear p r" will make
a difference when re-entering "r". You cannot just re-enter "r:=..." to
redefine "r" without generating a "none was determined to be applicable"
message. Sometimes, you have to ")clear p r" first. That's very confusing
for a new user, assuming oa is _suppose_ be that way, but I digress...

solve(xe=xt)

(6) -> solve(xe=xt)
Compiling body of rule bt to compute value of type Expression
Integer
Compiling body of rule xe to compute value of type Expression
Integer
Compiling body of rule xt to compute value of type Expression
Integer

>> Error detected within library code:
catdef: division by zero

(6) -> solve(1/xe=1/xt)

+----+ +----+
13|2569 + 1369 - 13|2569 + 1369
(6) [s= 0,s= ----------------,s= ------------------]
25 25
Type: List Equation Expression Integer

Now, HyperDoc says

Notice that the type of second argument controls the type of the
result. If you give a floating-point precision you get a
floatiing-point result;...

So:
(7) -> solve(1/xe=1/xt,0.0000001)
There are 20 exposed and 3 unexposed library operations named solve
having 2 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op solve
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 solve
with argument type(s)
Equation Expression Integer
Float

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

(7) -> (-13*sqrt(2569)+1369)/25

+----+
- 13|2569 + 1369
(7) ------------------
25
Type: AlgebraicNumber
(8) -> (-13*sqrt(2569)+1369)/25.

(8) 28.4036421332 53691913

(9) -> solve(1/xe=1/xt)::Float

Cannot convert from type List Equation Expression Integer to Float
for value
+----+ +----+
13|2569 + 1369 - 13|2569 + 1369
[s= 0,s= ----------------,s= ------------------]
25 25

(9) -> solve(1/xe=1/xt)@Float
There are 8 exposed and 2 unexposed library operations named solve
having 1 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op solve
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 solve
with argument type(s)
Equation Expression Integer

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

(9) -> solve(1/xe=1/xt)$Float

The function solve is not implemented in Float .

I could find no way to coerce oa into printing out the results for "s" as
floating-point numbers, other than to re-enter them _by_hand_.

That seems silly, but what is up with "solve(1/xe=1/xt,0.0000001)"? That
seems like a legal command with proper argument types. Maybe a bug?

Thanks

James