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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
