Subject: (1.0+%i)^0.5 does not evaluate numerically
From: Dieter Kaiser
Date: Sat, 04 Jul 2009 15:29:08 +0200
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