How to make sqrt(-1) be 1j

Tim Hochberg tim.hochberg at
Fri Oct 13 00:13:53 CDT 2006

Bill Baxter wrote:
> I think efficiency is not a very good argument for the default
> behavior here, because -- lets face it -- if efficient execution was
> high on your priority list, you wouldn't be using python.  
I care very much about efficiency where it matters, which is only in a 
tiny fraction of my code. For the stuff that numpy does well it's pretty 
efficient, when that's not enough I can drop down to C, but I don't have 
to do that often. In fact, I've argued and still believe, that Python is 
frequently *more* efficient than C, given finite developer time, since 
it's easier to get the algorithms correct writing in Python.
> And even if
> you do care about efficiency, one of the top rules of optimization is
> to first get it working, then get it working fast.
IMO, the current behavior is more likely to give you working code than 
auto-promoting to complex based on value. That concerns me more than 
efficiency. The whole auto-promotion thing looks like a good way to 
introduce data dependent bugs that don't surface till late in the game 
and are hard to track down. In contrast, when the current scheme causes 
a problem it should surface almost immediately. I would not use 
scipy.sqrt in code, even if the efficiency were the same, for this reason.

I can see the attraction in the autopromoting version for teaching 
purposes and possibly for throwaway scripts, but not for "real" code.
> Really, I'm just playing the devils advocate here, because I don't
> work with complex numbers (I see quaternions more often than complex
> numbers).  But I would be willing to do something like
>         numpy.use_realmath()
> in my code if it would make numpy more palatable to a wider audience.
> I wouldn't like it, however, if I had to do some import thing where I
> have to remember forever after that I should type 'numpy.tanh()' but
> 'realmath.arctanh()'.
As I mentioned in my other message, the way to do this is to have a 
different entry point with different behavior.
> Anyway it seems like the folks who care about performance are the ones
> who will generally be more willing to make tweaks like that.
It's not just about performance though. It's also about correctness, or 
more accurately, resistance to bugs.
> But that's about all I have to say about this, since the status quo
> works fine for me.  So I'll be quiet.  Just it seems like the
> non-status-quo'ers here have some good points.  I taught intro to
> computer science to non-majors one semester.  I know I would not want
> to have to confront all the issues with numerical computing right off
> the bat if I was just trying to teach people how to do some math.
There's probably nothing wrong with having a package like this, it just 
shouldn't be numpy. It's easy enough to construct such a beast for 
yourself, it should take just a few lines of Python. Since what a 
beginners package should look like probably varies from teacher to 
teacher, let them construct a few. If they all, or at least most of 
them, have the same ideas about what constitutes such a package, that 
might be to the time to think about officially supporting a separate 
entry point that has the modified behaviour. For the moment, things look 


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list