How to make sqrt(-1) be 1j

Tim Hochberg tim.hochberg at ieee.org
Fri Oct 13 01:13:53 EDT 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 
fine.

-tim



-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642




More information about the NumPy-Discussion mailing list