Fernando Perez wrote: > Please note that I see a valid reason for scipy.foo != numpy.foo when > the scipy version uses code with extra features, is faster, has > additional options, etc. But as I said in a previous message, I think > that /for the same input/, we should really try to satisfy that > > numpy.foo(x) == scipy.foo(x) (which is NOT the same as 'numpy.foo is > scipy.foo') > > within reason.
As far as I can tell this is exactly what happens. Consider the issue under discussion... ---------------------------------- >>> import numpy as np >>> np.sqrt(-1) -1.#IND >>> np.sqrt(-1+0j) 1j >>> a = complex(-1) >>> np.sqrt(a) 1j >>> import scipy as sp >>> sp.sqrt(-1) -1.#IND >>> np.sqrt(-1+0j) 1j >>> sp.sqrt(a) 1j >>> np.__version__ '1.0rc1' >>> sp.__version__ '0.5.1' >>> ---------------------------------- I'm sure that this hasn't changed in the development versions. Surely the point is that when your algorithm can potentially produce a complex result, the logical thing to do is to use a complex data type. In this case Numpy and Scipy behave in a way which is intuitive. If complex results are surprising and unexpected then the algorithm is probably in error or poorly understood ;-) Cheers, Scott ------------------------------------------------------------------------- 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
