I'm not convinced that the "pickiness" of Julia's square root is a serious 
problem.  Python's sqrt(x) behaves the same way for real x, and it hasn't 
been an obstacle to SciPy's adoption.  For that matter, in strongly typed 
languages like C and Fortran this has pretty much always been the behavior 
(giving NaN for sqrt of a negative real argument), and having to know 
whether you need a real or complex sqrt has not been a serious hindrance to 
scientific computing in those languages either.

In practice, in real engineering/physics applications, when you take the 
square root of a real quantity you usually know whether it is possible for 
that quantity to be negative, because the real-ness of the square root has 
physical significance.    In the relatively rare cases where you are taking 
the square root of a real quantity that may or may not be negative, you can 
always use sqrt(complex(x)).

Realize that there are three choices here:

1) Have sqrt(x) always return a complex result (equivalent to 
sqrt(complex(x)) for real arguments.  Then you pay a significant overhead 
(in memory and time and other complications) from using complex numbers 
everywhere that you have a sqrt, even in the common case where you don't 
need them.  (This is *not Julia-specific*: complex numbers are more 
expensive than real numbers in *any* language.)

2) Have sqrt(x) return a real result for positive real arguments and a 
complex result for negative real arguments (i.e., Matlab's behavior).   
This makes the function "type unstable" -- all code touched by the result 
of the sqrt is "poisoned" for the compiler, since the compiler has to 
compile two branches (one if the value is real and one if it is complex) 
that are tested at *runtime*.  This is one of many things that makes it 
difficult to compile Matlab to fast code, despite all of the resources that 
Mathworks has poured into JIT compilers.

3) The Julia (and Python) behavior: sqrt of a real value always returns a 
real value, but throws an exception if you pass it a negative real value. 
 This allows fast code to be compiled (at least for Julia; Python has other 
problems).  If you want a complex result, give sqrt a complex argument.  In 
practice, you usually know when this might occur in real applications, but 
in the worst case your code just throws and exception, and when you notice 
this you go back and change that sqrt call appropriately.

--SGJ

Reply via email to