On 10/13/06, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
> On 10/12/06, Bill Baxter <[EMAIL PROTECTED]> wrote:
> > On 10/12/06, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 12, 2006 at 08:58:21AM -0500, Greg Willden wrote:
> > > > On 10/11/06, Bill Baxter < [EMAIL PROTECTED]> wrote:
> > > I tried to explain the argument at
> > >
> > > http://www.scipy.org/NegativeSquareRoot
> > >
> >
> > The proposed fix for those who want sqrt(-1) to return 1j is:
> >
> > from numpy.lib import scimath as SM
> > SM.sqrt(-1)
> >
> >
> > But that creates a new namespace alias, different from numpy. So I'll
> > call numpy.array() to create a new array, but SM.sqrt() when I want a
> > square root.
> > Am I wrong to want some simple way to change the behavior of
> > numpy.sqrt itself?
> >
> > Seems like you can get that effect via something like:
> >
> > for n in numpy.lib.scimath.__all__:
> > numpy.__dict__[n] = numpy.lib.scimath.__dict__[n]
>
> I don't like either of those ideas, although the second seems preferable. I
> think it better to make an efficient way of calling a sqrt routine that
> accepts negative floats and returns complex numbers. The behaviour could be
> chosen either by key word or by specially named routines, or maybe even
> some global flag,
We have the "specially named routines" way already. "numpy.lib.scimath.sqrt"
> but I don't think it asking too much for the students to
> learn that sqrt(-1) doesn't exist as a real number and that efficient
> computation uses real whenever possible because it is a) smaller, and b)
> faster. That way we also avoid having software that only works for scimath
> but not for numpy.
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. 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.
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()'.
Anyway it seems like the folks who care about performance are the ones
who will generally be more willing to make tweaks like that.
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.
--bb
-------------------------------------------------------------------------
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
