# [Maxima] (1.0+%i)^0.5 does not evaluate numerically

Dieter Kaiser drdieterkaiser at web.de
Sat Jul 4 08:29:08 CDT 2009

```In Maxima we have the convention that if the arguments to a function are
numbers and one of the arguments is a floating point or bigfloat number
the function is numerically evaluated.

This is not fully true for the power function. The power function does
not evaluate numerically, if one of the arguments is a complex number,
e.g.

(%i86) (1.0+%i)^0.5;
(%o86) (%i+1.0)^0.5
(%i88) (2.0)^(0.5+%i);
(%o88) 2.0^(%i+0.5)

This causes inconsistencies and problems.

The sqrt function evaluates numerically as expected:

(%i89) sqrt(1.0+%i);
(%o89) .4550898605622273*%i+1.09868411346781

But not the equivalent expression:

(%i90) (1.0+%i)^(1/2);
(%o90) sqrt(%i+1.0)

I have observed the inconsistent behavior using the functionality of
mapping over lists:

The expressions are not fully evaluated numerically:

(%i99) sqrt([1.0*%i,2.0*%i,4.0*%i]);
(%o99) [sqrt(1.0*%i),1.414213562373095*(-1)^(1/4),2.0*(-1)^(1/4)]

But when we do not use a mapping we get:

(%i100) sqrt(1.0*%i);
(%o100) .7071067811865475*%i+.7071067811865476
(%i101) sqrt(2.0*%i);
(%o101) 1.0*%i+1.0
(%i102) sqrt(4.0*%i);
(%o102) 1.414213562373095*%i+1.414213562373095

Often we can do an extra rectform to get the desired numerically
evaluation. But there are cases even one rectform does not help:

(%i111) (4.0*%i)^0.5;
(%o111) 2.0*(-1)^0.25
(%i112) rectform(%),numer;
(%o112) 2.0*%i*sin(0.25*%pi)+2.0*cos(0.25*%pi)
(%i113) rectform(%),numer;
(%o113) 1.414213562373095*%i+1.414213562373095

This causes sometimes problems when evaluating functions with complex
arguments:

(%i119) sin((4.0*%i)^0.5);
(%o119) sin(2.0*(-1)^0.25)
(%i120) rectform(%);
(%o120) %i*cos(2.0*cos(0.25*%pi))*sinh(2.0*sin(0.25*%pi))
+sin(2.0*cos(0.25*%pi))*cosh(2.0*sin(0.25*%pi))
(%i122) rectform(%),numer;
(%o122) .3017614698677608*%i+2.151535541339286

I think this should be the expected behavior:

(%i123) sin(sqrt(4.0*%i));
(%o123) .3017614698677608*%i+2.151535541339286

Do you think we should call the missing numerically evaluation for
complex numbers a bug and implement the missing numerical evaluation?

Dieter Kaiser

```