How to make sqrt(-1) be 1j
tim.hochberg at ieee.org
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
> 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
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