Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: [EMAIL PROTECTED] wrote: Could sqrt(-1) made to return 1j again? Not in NumPy. But, in scipy it could. Ohmigod!!! You are definitely going to scare away many, many potential users - if I wasn't obliged to use open source at work, you'd be scaring me away. I was thinking about translating all my personal fractal-generating Matlab code into Python, but I certainly won't be doing that now! - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Sven Schreiber wrote: Travis Oliphant schrieb: If not, shouldn't numpy.sqrt(-1) raise a ValueError instead of returning silently nan? This is user adjustable. You change the error mode to raise on 'invalid' instead of pass silently which is now the default. -Travis Could you please explain how this adjustment is done, or point to the relevant documentation. Thank you, Sven I'm glad you asked this, Sven, 'cause I was thinking that if making this user adjustment is this advanced (I too have no idea what you're talking about, Travis), then this would be another significant strike against numpy (but I was holding my tongue, since I'd just let fly in my previous email). DG - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
David Goldsmith wrote: Travis Oliphant wrote: [EMAIL PROTECTED] wrote: Could sqrt(-1) made to return 1j again? Not in NumPy. But, in scipy it could. Ohmigod!!! You are definitely going to scare away many, many potential users - if I wasn't obliged to use open source at work, you'd be scaring me away. Why in the world does it scare you away. This makes no sense to me. If you don't like the scipy version don't use it. NumPy and SciPy are not the same thing. The problem we have is that the scipy version (0.3.2) already had this feature (and Numeric didn't). What is so new here that is so scary ? -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: This is the one that concerns me. Slowing everybody down who knows they have positive values just for people that don't seems problematic. Then have a sqrtp function for those users who are fortunate enough to know ahead of time that they'll only be talking square roots of nonnegatives. DG - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
David Goldsmith wrote: Travis Oliphant wrote: What could be simpler? ;-) Having sqrt(-1) return 1j (without having to remember that in order to get this, you have to write sqrt(-1+0j) instead). But this can sometimes lead to confusing errors hard to track when you don't want to treat complex numbers. That's one of the thing I hated in matlab, actually: if you don't want to handle complex numbers, you have to check regularly for it. So I don't think this is simpler. David - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
David Goldsmith wrote: Travis Oliphant wrote: What could be simpler? ;-) Having sqrt(-1) return 1j (without having to remember that in order to get this, you have to write sqrt(-1+0j) instead). That's exactly what scipy.sqrt(-1) does. That was my point. -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/12/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Why in the world does it scare you away. This makes no sense to me.
If you don't like the scipy version don't use it. NumPy and SciPy are
not the same thing.
I'd like to pitch in (again) on this issue, but I'll try to make sure
that it's clear that I'm NOT arguing about sqrt() in particular, one
way or another.
It's perfectly clear that numpy != scipy to all of us. And yet, I
think it is equally clear that the two are /very/ tightly related.
Scipy builds on top of numpy and it directly exposes a LOT of the
numpy API as scipy functions:
In [21]: import numpy as n, scipy as s
In [22]: common_names = set(dir(n)) set(dir(s))
In [23]: [getattr(n,x) is getattr(s,x) for x in common_names ].count(True)
Out[23]: 450
In [24]: len(common_names)
Out[24]: 462
That's 450 objects from numpy which are directly exposed in Scipy,
while only 12 names are in both top-level namespaces and yet are
different objects. Put another way, scipy is a direct wrap of 97% of
the numpy top-level namespace. While /we/ know they are distinct
entities, to the casual user a 97% match looks pretty close to being
the same, especially when the non-identical things are all
non-numerical:
In [27]: [x for x in common_names if getattr(n,x) is not getattr(s,x)]
Out[27]:
['pkgload',
'version',
'__config__',
'__file__',
'__all__',
'__doc__',
'show_config',
'__version__',
'__path__',
'__name__',
'info',
'test']
In [32]: n.__version__,s.__version__
Out[32]: ('1.0.dev3306', '0.5.2.dev2252')
Basically, at least for these versions, the top-level API of scipy is
a strict superset of the numpy one for all practical purposes.
I think it's fair to say that if we start sprinkling special cases
where certain objects happen to have the same name but produce
different results for the same inputs, confusion will arise.
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. Obviously the scipy version may succeed where the
numpy one fails due to better algorithms, or be faster, etc. I'm
talking about a general principle here.
I doubt I'll be able to state my point with any more clarity, so I'll
stop now. But I really believe that this particular aspect of
consistency between numpy and scipy is a /very/ important one for its
adoption in wider communities.
Best,
f
-
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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: David Goldsmith wrote: Travis Oliphant wrote: [EMAIL PROTECTED] wrote: Could sqrt(-1) made to return 1j again? Not in NumPy. But, in scipy it could. Ohmigod!!! You are definitely going to scare away many, many potential users - if I wasn't obliged to use open source at work, you'd be scaring me away. Why in the world does it scare you away. This makes no sense to me. If you don't like the scipy version don't use it. NumPy and SciPy are not the same thing. I don't use scipy (and don't want to because of the overhead) but it sounds like I should because if I'm taking the square root of a variable whose value at run time happens to be real but less than zero, I *want* the language I'm using to return an imaginary; in other words, it's not the scipy behavior which scares me, its the numpy (which I do/have been using) behavior. To which you might say, Well, if that's what you want, and you have Matlab (as you've said you do), then just use that. But that's precisely the point: people who don't want to be bothered with having to be a bit more care[ful] (as Chuck put it) - and who can afford it - are going to be inclined to choose Matlab over numpy. Perhaps one doesn't care - in the grand scheme of things, it certainly doesn't matter - but I think that you all should be aware that this numpy feature will be seen by many as more than just a nuisance. DG - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: David Goldsmith wrote: Travis Oliphant wrote: What could be simpler? ;-) Having sqrt(-1) return 1j (without having to remember that in order to get this, you have to write sqrt(-1+0j) instead). That's exactly what scipy.sqrt(-1) does. That was my point. But I don't want to have to use scipy (which so far I haven't needed for any other reason) just to get this one behavior. But my personal preferences aside, I say again: if numpy doesn't behave this way, you *will* be scaring away many potential users. If you can live with that, so be it. DG DG -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
(Very) well said, Fernando. Thanks!
DG
Fernando Perez wrote:
On 10/12/06, Travis Oliphant [EMAIL PROTECTED] wrote:
Why in the world does it scare you away. This makes no sense to me.
If you don't like the scipy version don't use it. NumPy and SciPy are
not the same thing.
I'd like to pitch in (again) on this issue, but I'll try to make sure
that it's clear that I'm NOT arguing about sqrt() in particular, one
way or another.
It's perfectly clear that numpy != scipy to all of us. And yet, I
think it is equally clear that the two are /very/ tightly related.
Scipy builds on top of numpy and it directly exposes a LOT of the
numpy API as scipy functions:
In [21]: import numpy as n, scipy as s
In [22]: common_names = set(dir(n)) set(dir(s))
In [23]: [getattr(n,x) is getattr(s,x) for x in common_names ].count(True)
Out[23]: 450
In [24]: len(common_names)
Out[24]: 462
That's 450 objects from numpy which are directly exposed in Scipy,
while only 12 names are in both top-level namespaces and yet are
different objects. Put another way, scipy is a direct wrap of 97% of
the numpy top-level namespace. While /we/ know they are distinct
entities, to the casual user a 97% match looks pretty close to being
the same, especially when the non-identical things are all
non-numerical:
In [27]: [x for x in common_names if getattr(n,x) is not getattr(s,x)]
Out[27]:
['pkgload',
'version',
'__config__',
'__file__',
'__all__',
'__doc__',
'show_config',
'__version__',
'__path__',
'__name__',
'info',
'test']
In [32]: n.__version__,s.__version__
Out[32]: ('1.0.dev3306', '0.5.2.dev2252')
Basically, at least for these versions, the top-level API of scipy is
a strict superset of the numpy one for all practical purposes.
I think it's fair to say that if we start sprinkling special cases
where certain objects happen to have the same name but produce
different results for the same inputs, confusion will arise.
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. Obviously the scipy version may succeed where the
numpy one fails due to better algorithms, or be faster, etc. I'm
talking about a general principle here.
I doubt I'll be able to state my point with any more clarity, so I'll
stop now. But I really believe that this particular aspect of
consistency between numpy and scipy is a /very/ important one for its
adoption in wider communities.
Best,
f
-
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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-
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=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
I'd like to pitch in (again) on this issue, but I'll try to make sure that it's clear that I'm NOT arguing about sqrt() in particular, one way or another. Fernando, I don't disagree with you in principle. I don't think anybody does. I think we should try to keep the interfaces and expectations of scipy and numpy the same. Unfortunately, we have competing issues in this particular case (in the case of the functions in numpy.lib.scimath). Nobody has suggested an alternative to the current situation in SVN that is satsifying to enough users. Here is the situation. 1) NumPy ufuncs never up-cast to complex numbers without the user explicitly requesting it so sqrt(-1) creates a floating-point error condition which is either caught or ignored according to the user's desires.To get complex results from sqrt you have put in complex numbers to begin with. That's inherent in the way ufuncs work. This is long-standing behavior that has good reasons for it's existence. I don't see this changing.That's why I suggested to move the discussion over to scipy (we have the fancy functions in NumPy, they are just not in the top-level name-space). Now, it would be possible to give ufuncs a dtype keyword argument that allowed you to specify which underlying loop was to be used for the calculation. That way you wouldn't have to convert inputs to complex numbers before calling the ufunc, but could let the ufunc do it in chunks during the loop. That is certainly a reasonable enhancement: sqrt(a, dtype=complex). This no-doubt has a library-ish-feeling, but that is what NumPy is. If such a change is desireable, I don't think it would be much to implement it. 2) In SciPy 0.3.2 the top-level math functions were overloaded with these fancy argument-checking versions. So that scipy.sqrt(-1) would return 1j. This was done precisely to attract users like David G. who don't mind data-type conversions on the fly, but prefer automatic conversion (funny being called non-sensical when I was the one who wrote those original scipy functions --- I guess I'm schizophrenic). We changed this in SciPy 0.5.1 by accident without any discussion. It was simply a by-product of moving scipy_base (including those special-handling functions) into NumPy and forgetting to import those functions again into top-level SciPy.It was an oversight that caused backwards compatibilty issues. So, I simply changed it back to what SciPy used to be in SVN. If we want to change SciPy, then fine, but let's move that discussion over to scipy-dev. In short, I appreciate all the comments and the differences of opinion they point out, but they are ultimately non-productive. We can't just change top-level sqrt to be the fancy function willy-nilly. Paul says I'm nice (he's not talked to my children recently), but I'm not that much of a push-over. There are very good reasons that NumPy has the behavior it does. In addition, the fancy functions are already there in numpy in numpy.lib.scimath. So, use them from there if you like them. Create your own little mynumpy module that does from numpy import * from numpy.lib.scimath import * and have a ball. Python is flexible enough that the sky is not going to fall if the library doesn't do things exactly the way you would do it. We can still cooperate in areas that we agree on. Again. Put this to rest on NumPy and move the discussion over to scipy-dev. -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
David Goldsmith wrote: I don't use scipy (and don't want to because of the overhead) but it sounds like I should because if I'm taking the square root of a variable whose value at run time happens to be real but less than zero, I *want* the language I'm using to return an imaginary; in other words, it's not the scipy behavior which scares me, its the numpy (which I do/have been using) behavior. O.K. Well the functions you want are in numpy.lib.scimath. I should have directed you there. You actually don't need scipy installed at all. Just import sqrt from numpy.lib.scimath. I'm sorry I misunderstood the issue. -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
PS: I am still sending this message to numpy list only because the proposal below affects numpy code, not scipy one. I think Fernando points make sense, numpy.foo(x) != scipy.foo(x) can cause confusion and frustration both among new numpy/scipy users and developers (who need to find explanations for the choises made). So, let me propose the following solution so that all parties will get the same results without sacrifying numpy.sqrt speed on non-negative input and scipy.sqrt backward compatibility: Define numpy.sqrt as follows: def sqrt(x): r = nx.sqrt(x) if nx.nan in r: i = nx.where(nx.isnan(r)) r = _tocomplex(r) r[i] = nx.sqrt(_tocomplex(x[i])) return r and define numpy.sqrtp that takes only non-negative input, this is for those users who expect sqrt to fail on negative input (as Numeric.sqrt and math.sqrt do). Pearu - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
My vote is for consistency in numpy.But it is unclear what consistency is.What is truly confusing for newbie Python users (and a source for error even after 5 years of Python programming) is that 2/3 0In that respect, I would think numpy.sqrt(2)should give 1, but it gives 1.4142135623730951So numpy does typechecking anyway (it gets an integer and makes it a float). If that is the consistent behavior, then by all means sqrt(-1)should return 1j.Wouldn't that be the consistent thing to doMark - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
I've summarised this thread at http://www.scipy.org/NegativeSquareRoot Feel free to make adjustments, in case I missed something. Regards Stefan - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Bill Baxter [EMAIL PROTECTED] wrote: On 10/12/06, Greg Willden [EMAIL PROTECTED] wrote: Speed should not take precedence over correctness.Unless your goal is speed.Then speed should take precedence over correctness. Huh?Person 1: Hey you should use function X.Person 2: No, it doesn't give me the correct answer.Person 1: Who cares? It's fast!What kind of logic is that? I'm having serious doubts about my conversion to Numpy.Greg - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Mark Bakker wrote: My vote is for consistency in numpy. But it is unclear what consistency is. What is truly confusing for newbie Python users (and a source for error even after 5 years of Python programming) is that 2/3 0 I recommend that you slap from __future__ import division into site.py or the top of your program: from __future__ import division import numpy print 3/2 a = numpy.arange(3) print a / (a+5) print a // a+5 1.5 [ 0. 0.1667 0.28571429] [5 6 6] In that respect, I would think numpy.sqrt(2) should give 1, but it gives 1.4142135623730951 Is there any practical reason to return 1? If not, isn't this argument sort of silly? So numpy does typechecking anyway (it gets an integer and makes it a float). If that is the consistent behavior, then by all means sqrt(-1) should return 1j. Well, it could also return: -1j or as someone mentioned one of six (I think) different quaternion values. It all depends on what the domain/range of the problem is. Wouldn't that be the consistent thing to do No, there's a difference. In order to do the former, all that is required is that sqrt switches on the *type* of it argument. sqrt return a float for integer and floating point args and a complex for complex args. In order to the latter, sqrt needs to switch on the *value* of its argument, which is an entirely different beast both in theory and in practice. In particular: sqrt(some_big_array) would have to scan all the values in the array to determine if any were negative to decide whether to return a float or an imaginary number. It also means that the memory usage is unpredictable -- the returned array is double in size if any values are negative. In addition to the significant slowdown this introduces, the former approach (keeping the input and output domains the same) is somewhat more robust against error, particularly if one tightens up the error mode. I would guess that people are working the complex plane at most half the time, in the former case a negative square root signals a problem and promoting to complex is at best a nuisance and may result in a painful to track down error. In the latter case, it's easy enough for me to toss in a astype in situations where I'm mixing domains and need complex outputs. Ideally numpy and scipy would have chosen different names for forgiving and strict powers and square roots, square_root and power versus sqrt and pow for example, but it's probably too late to do anything about that now. Since it sounds like Travis is going to tighten up the default error mode, I think that this is a non issue. No ones going to run into NANs unexpectedly and the error when doing sqrt([1,2,3,-1]) should be confusing and most once. -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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: Travis Oliphant wrote: Now, it would be possible to give ufuncs a dtype keyword argument that allowed you to specify which underlying loop was to be used for the calculation. That way you wouldn't have to convert inputs to complex numbers before calling the ufunc, but could let the ufunc do it in chunks during the loop. That is certainly a reasonable enhancement: sqrt(a, dtype=complex). This no-doubt has a library-ish-feeling, but that is what NumPy is. If such a change is desireable, I don't think it would be much to implement it. This could be implemented, but only with a version number increase in the C-API (we would have to change the c-signature of the ufunc tp_call. This would mean that the next release of NumPy would be binary incompatible with packages built to previous NumPy releases. I've really been trying to avoid doing that. So, unless there are strong requests for this feature that outweigh the negatives of re-building dependent packages, then this feature will have to wait. OTOH: I suppose it could be implemented in a different way (using indexing or a method call): sqrt[complex](a) --- I remember Tim suggesting some use for indexing on ufuncs earlier though. It wouldn't surprise me if I did -- it sounds like the kind of thing I'd propose -- but I certainly can't remember what I was proposing. -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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On Thu, Oct 12, 2006 at 08:58:21AM -0500, Greg Willden wrote: On 10/11/06, Bill Baxter [EMAIL PROTECTED] wrote: On 10/12/06, Greg Willden [EMAIL PROTECTED] wrote: Speed should not take precedence over correctness. Unless your goal is speed. Then speed should take precedence over correctness. Huh? Person 1: Hey you should use function X. Person 2: No, it doesn't give me the correct answer. Person 1: Who cares? It's fast! What kind of logic is that? I tried to explain the argument at http://www.scipy.org/NegativeSquareRoot Cheers Stéfan - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: Personally I think that the default error mode should be tightened up. Then people would only see these sort of things if they really care about them. Using Python 2.5 and the errstate class I posted earlier: # This is what I like for the default error state numpy.seterr (invalid='raise', divide='raise', over='raise', under='ignore') I like these choices too. Overflow, division by zero, and sqrt(-x) are usually errors, indicating bad data or programming bugs. Underflowed floats, OTOH, are just really, really small numbers and can be treated as zero. An exception might be if the result is used in division and no error is raised, resulting in a loss of accuracy. I'm fine with this. I've hesitated because error checking is by default slower. But, I can agree that it is less surprising to new-comers. People that don't mind no-checking can simply set their defaults back to 'ignore' Great. One thing we may want to do (numarray had this), was add a pseudo argument 'all', that allows you to set all of the values at once. Then if you want the full-bore, ignore-all-errors computation (and your using 2.5 and from __future__ import with_statement) you can just do: with errstate(all='ignore'): # computation here # back to being picky -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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
I'll try to quit being a pain and just work around it.Those wiki pages are really good to capture this information. I need to read all of them to know what other gotchas are out there.Thanks and Sorry,Greg On 10/12/06, Alan G Isaac [EMAIL PROTECTED] wrote: That's fine, but be sure to treat the explanations you arereceiving with the same seriousness that you treat yourdoubts.For example, in the speed vs. correctness discussion, besure to understand the problems with the word correct. Which have been explained.correct != expectedwhen expectations lack context - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
May I suggest the following change to generate_umath.py?completely untested string change'sqrt' : Ufunc(1, 1, None, 'square-root elementwise. For real x, the domain is restricted to x=0.\n\ For complex results for x0 see numpy.scimath.sqrt', TD(inexact, f='sqrt'), TD(M, f='sqrt'), ),'When sqrt throws a ValueError would it be possible/appropriate for the error message to mention numpy.scimath.sqrt?I'm just trying to think of other ways to help make the transition as smooth as possible for new users.Greg - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Tim Hochberg wrote: Travis Oliphant wrote: Tim Hochberg wrote: With python 2.5 out now, perhaps it's time to come up with a with statement context manager. Something like: a = numpy.arange(10) a/a # ignores divide by zero with errstate(divide='raise'): a/a # raise exception on divide by zer # Would ignore divide by zero again if we got here. -tim This looks great. I think most people aren't aware of the with statement and what it can do (I'm only aware because of your posts, for example). So, what needs to be added to your example in order to just add it to numpy? As far as I know, just testing and documentation -- however testing was so minimal that I may find some other stuff. I'll try to clean it up tomorrow so that I'm a little more confident that it works correctly and I'll send another note out then. For this particular application, why not a context manager which just substitutes in the appropriately-optimized version of sqrt? That is, don't change the error state, but actually change the value of the object pointed at by the name sqrt? Andrew - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than?nan?
On Thu, Oct 12, 2006 at 10:53:12AM -0400, Alan G Isaac wrote: On Thu, 12 Oct 2006, Stefan van der Walt apparently wrote: I tried to explain the argument at http://www.scipy.org/NegativeSquareRoot Helpful. But you start off by saying: In mathematics, the above assumption is true -- that the square root of -1 is 1j. Since square root is (here) a function, and part of the function definition is the domain and codomain, this statement is not correct. If the codomain is real numbers, the domain must correspondingly be (a subset of) the nonnegative reals. The nan output is the result of an **invalid** input. So the question is really: Why is a negative real number an invalid input in this implementation, or Why in this implementation is the type of the output restricted by the type of the input? You get a good start on answering that. You are more than welcome to change the wiki if you can think of a simpler way to explain the problem... In fact, I would encourage that -- I just put it there as a starting point. Cheers Stéfan - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Greg Willden wrote: May I suggest the following change to generate_umath.py? completely untested string change 'sqrt' : Ufunc(1, 1, None, 'square-root elementwise. For real x, the domain is restricted to x=0.\n\ For complex results for x0 see numpy.scimath.sqrt', TD(inexact, f='sqrt'), TD(M, f='sqrt'), ), ' When sqrt throws a ValueError would it be possible/appropriate for the error message to mention numpy.scimath.sqrt? I'm just trying to think of other ways to help make the transition as smooth as possible for new users. And helpful error messages are one of Python's best features - in general, numpy doesn't have enough of 'em, IMO. DG Greg - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
As someone on this list (sorry to quick with the delete button) said: numpy is closer to the metal than MATLAB MATLAB aside, numpy is somewhat close to the metal. I think this is clearly part of its design philosophy, and also something I personally like about out. Getting back to MATLAB (at least version 4, the last one I used regularly) -- everything in MATLAB is a matrix of double precision Floating points. (or complex - that does get weird!). This makes things simpler for a lot of use, but restricts the power and flexibility substantially. Everything in numpy is an array of arbitrary shape and many possible data types -- this is more to think about, but give you a lot of power and flexibility. In any case, that is what numpy is. Period. Given that, arrays of different types behave differently -- that's something you'd darn well better understand pretty soon in your numpy career: a = N.array((1,2,3), dtype=N.uint8) a *= 200 a array([200, 144, 88], dtype=uint8) Oh my gosh! 2 * 200 isn't 144! what happened? This isn't any different than sqrt(-1) resulting in NaN or an error. In fact, there are all sorts of places where upcasting is not happening automagically -- in fact, I think that's become more consistent in the new numpy. So, in numpy you need to choose the datatype appropriate for your problem at hand. I know I always know whether I want to work in the complex plane or not. Another change recently made is to make doubles the default in more places -- I like that change. So, given the entire philosophy and current status of how numpy works, the ONLY question that is legitimate here is: Should the default datatype be complex or double? I vote double. Travis Oliphant wrote: Now, it would be possible to give ufuncs a dtype keyword argument that allowed you to specify which underlying loop was to be used for the calculation. sqrt(a, dtype=complex). I like this OK, and isn't is similar to the dtype argument in the accumulating methods? (sum, etc.). However, it's probably not worth the C-api change -- is it that different than calling: sqrt(a.astype(complex)) ? As for scipy, I heartily agree that scipy should be a superset of numpy, and NOT change the behavior of numpy functions and methods. We're taking the opportunity at this point for numpy to break backward compatibility with Numeric/numarray -- this is probably the best time to do the same for scipy. couldn't we at least introduce new names? numpy.scimath.csqrt() for instance? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Hi, On Thursday 12 October 2006 10:49, Christopher Barker wrote: As someone on this list (sorry to quick with the delete button) said: snip I think I might agree with everything (!) you that - very well written . Travis Oliphant wrote: Now, it would be possible to give ufuncs a dtype keyword argument that allowed you to specify which underlying loop was to be used for the calculation. sqrt(a, dtype=complex). I like this OK, and isn't is similar to the dtype argument in the accumulating methods? (sum, etc.). However, it's probably not worth the C-api change -- is it that different than calling: sqrt(a.astype(complex)) ? It is very late in the game - obvious ! (one week before the announced final release). But I think adding the dtype argument to ufuncs would be a very useful addition !! It is very nice to look at ! And it saves (temporary) memory and should be noticeably faster than sqrt(a.astype(complex)). This dtype addition might address many of the issues I have raised before on this list. Travis, be courageous and change the C-API one last time before putting it in stone for 1.0 final !!! As for scipy, I heartily agree that scipy should be a superset of numpy, and NOT change the behavior of numpy functions and methods. We're taking the opportunity at this point for numpy to break backward compatibility with Numeric/numarray -- this is probably the best time to do the same for scipy. couldn't we at least introduce new names? numpy.scimath.csqrt() for instance? -Chris It has to be very well documented what the 12 functions (the last 3%) are were scipy and numpy differ. --- if at all possible I would prefer a name change like csqrt (or better sqrtc - I always like seen things together when sorted alphabetically ;-) ) [by the way: I like sqrt(-1) == nan just fine] Thanks for the great work. - Sebastian - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Historical note. When Cleve Moler first created 'matlab' as a tool for teaching at the University of New Mexico, all numbers were complex. And, in fact, there was a limit of 10,000 numbers. There was a fixed array where these 10,000 numbers were stored. I got pretty excited about his project and wanted to use it to get eigenvalues etc. for matrices of interest from our codes. But I had a Cray 1 with an entire megaword of memory and my matrices wouldn't fit. So I set out to hack the code to add a memory manager so that we could use the entire memory. This was a big success. Then I decided it was sad that I had to write the matrices out of the code onto a disk and then read them into matlab, so I got the idea of making something similar as the front end of the code, only with data types (because I hated only being able to use half my Cray since my data was real, and our codes were often memory bound) and a full programming language like Fortran with array syntax for speed. This idea resulted in Basis ( basis.llnl.gov). My interest in Python (and hence numpy) evolved from that as OOP arrived. - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
David Goldsmith wrote: Got it. And if I understand correctly, the import order you specify in the little mynumpy example you included in your latest response to Fernando will result in any overlap between numpy and numpy.lib.scimath to call the latter's version of things rather than the former's, yes? Right. The last import will be used for any common-names (variables get re-bound to the new functions...) -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
I find that acceptable for my purposes, but is there some way we can minimize the surprise(s) for newbies? (I know some suggestions have been put forward in this thread, but I don't know enough to cast a vote one way or another for any of those, just a vote for please do it.) And, in closing, I too would like to: thank you very much for all your work - despite my emotional outburst, I am generally very happy using numpy and regard it as an excellent product. DG Travis Oliphant wrote: David Goldsmith wrote: Got it. And if I understand correctly, the import order you specify in the little mynumpy example you included in your latest response to Fernando will result in any overlap between numpy and numpy.lib.scimath to call the latter's version of things rather than the former's, yes? Right. The last import will be used for any common-names (variables get re-bound to the new functions...) -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
[EMAIL PROTECTED] wrote: Hi, I have recieved the following note from a user: In SciPy 0.3.x the ufuncs were overloaded by more intelligent versions. A very attractive feature was that sqrt(-1) would yield 1j as in Matlab. Then you can program formulas directly (e.g., roots of a 2nd order polynomial) and the right answer is always achieved. In the Matlab-Python battle in mathematics education, this feature is important. Now in SciPy 0.5.x sqrt(-1) yields nan. A lot of code we have, especially for introductory numerics and physics courses, is now broken. This has already made my colleagues at the University skeptical to Python as this lack of backward compatibility would never happen in Matlab. This was a consequence of moving scipy_base into NumPy but not exposing the scimath library in NumPy. It would be a very easy thing to put from numpy.lib.scimath import * into the scipy name-space. I'm supportive of that as a backward-compatibility measure. Another problem related to Numeric and numpy is that in these courses we use ScientificPython several places, which applies Numeric and will continue to do so. You then easily get a mix of numpy and Numeric in scripts, which may cause problems and at least extra overhead. Just converting to numpy in your own scripts isn't enough if you call up libraries using and returning Numeric. I wonder, what are the reasons that numpy.sqrt(-1) returns nan? Because that is backwards compatible. You have to construct a function-wrapper in order to handle the negative case correctly. The function wrapper is going to be slower. Thus, it is placed in a separate library. Could sqrt(-1) made to return 1j again? Not in NumPy. But, in scipy it could. If not, shouldn't numpy.sqrt(-1) raise a ValueError instead of returning silently nan? This is user adjustable. You change the error mode to raise on 'invalid' instead of pass silently which is now the default. -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant schrieb: If not, shouldn't numpy.sqrt(-1) raise a ValueError instead of returning silently nan? This is user adjustable. You change the error mode to raise on 'invalid' instead of pass silently which is now the default. -Travis Could you please explain how this adjustment is done, or point to the relevant documentation. Thank you, Sven - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Sven Schreiber wrote: This is user adjustable. You change the error mode to raise on 'invalid' instead of pass silently which is now the default. -Travis Could you please explain how this adjustment is done, or point to the relevant documentation. numpy.sqrt(-1) old = seterr(invalid='raise') numpy.sqrt(-1) # should raise an error seterr(**old) # restores error-modes for current thread numpy.sqrt(-1) - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Travis Oliphant [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Could sqrt(-1) made to return 1j again? Not in NumPy. But, in scipy it could. Without taking sides on which way to go, I'd like to -1 the idea of a difference in behavior between numpy and scipy. IMHO, scipy should be within reason a strict superset of numpy. Gratuitious differences in behavior like this one are going to drive us all mad. There are people who import scipy for everything, others distinguish between numpy and scipy, others use numpy alone and at some point in their life's code they do import numpy as N - import scipy as N because they start needing stuff not in plain numpy. Having different APIs and behaviors appear there is, I think, a Seriously Bad Idea (TM). Just my 1e-2j, Cheers, f - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: Sven Schreiber wrote: This is user adjustable. You change the error mode to raise on 'invalid' instead of pass silently which is now the default. -Travis Could you please explain how this adjustment is done, or point to the relevant documentation. numpy.sqrt(-1) old = seterr(invalid='raise') numpy.sqrt(-1) # should raise an error seterr(**old) # restores error-modes for current thread numpy.sqrt(-1) With python 2.5 out now, perhaps it's time to come up with a with statement context manager. Something like: from __future__ import with_statement import numpy class errstate(object): def __init__(self, **kwargs): self.kwargs = kwargs def __enter__(self): self.oldstate = numpy.seterr(**self.kwargs) def __exit__(self, *exc_info): numpy.seterr(**self.oldstate) a = numpy.arange(10) a/a # ignores divide by zero with errstate(divide='raise'): a/a # raise exception on divide by zer # Would ignore divide by zero again if we got here. -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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Travis Oliphant [EMAIL PROTECTED] wrote: Fernando Perez wrote: IMHO, scipy should be within reason a strict superset of numpy. This was not the relationship of scipy to Numeric. For me, it's the fact that scipy *used* to have the behavior that scipy.sqrt(-1) return 1j and now doesn't that is the kicker. That's fine, my only point was that we should really strive for consitency between the two. I think most users should be able to expect that numpy.foo(x) == scipy.foo(x) for all cases where foo exists in both. The scipy.foo() call might be faster, or take extra arguments for flexibility, and the above might only be true within floating point accuracy (since a different algorithm may be used), but hopefully functions with the same name do the same thing in both. I really think breaking this will send quite a few potential users running for the hills, and this is what I meant by 'superset'. Perhaps I wasn't clear enough. Cheers, f - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Travis Oliphant [EMAIL PROTECTED] wrote: Fernando Perez wrote: There are people who import scipy for everything, others distinguish between numpy and scipy, others use numpy alone and at some point in their life's code they do import numpy as N - import scipy as N because they start needing stuff not in plain numpy. Having different APIs and behaviors appear there is, I think, a Seriously Bad Idea (TM). I think the SBI is mixing numpy and scipy gratuitously (which I admit I have done in the past). I'm trying to repent Well, the problem is that it may not be so easy not to do so, esp. for new users. The fact that scipy absorbs and exposes many numpy functions makes this a particularly easy trap for anyone to fall into. The fact that even seasoned users do it should be an indicator that the 'right thing to do' is anything but obvious, IMHO. Once the dust settles on numpy 1.0, I think that the issues of how scipy plays with it, API consistency, coding best practices, etc, will need serious attention. But let's cross one bridge at a time :) Cheers, f - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On Wed, 11 Oct 2006, Travis Oliphant wrote: On the other hand requiring all calls to numpy.sqrt to go through an argument-checking wrapper is a bad idea as it will slow down other uses. Interestingly, in worst cases numpy.sqrt is approximately ~3 times slower than scipy.sqrt on negative input but ~2 times faster on positive input: In [47]: pos_input = numpy.arange(1,100,0.001) In [48]: %timeit -n 1000 b=numpy.sqrt(pos_input) 1000 loops, best of 3: 4.68 ms per loop In [49]: %timeit -n 1000 b=scipy.sqrt(pos_input) 1000 loops, best of 3: 10 ms per loop In [50]: neg_input = -pos_input In [52]: %timeit -n 1000 b=numpy.sqrt(neg_input) 1000 loops, best of 3: 99.3 ms per loop In [53]: %timeit -n 1000 b=scipy.sqrt(neg_input) 1000 loops, best of 3: 29.2 ms per loop nan's are making things really slow, Pearu - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Stefan van der Walt wrote: I agree with Fernando on this one. Further, if I understand correctly, changing sqrt and power to give the right answer by default will slow things down somewhat. But is it worth sacrificing intuitive usage for speed? For NumPy, yes. This is one reason that NumPy by itself is not a MATLAB replacement. N.power(2,-2) == 0 and N.sqrt(-1) == nan just doesn't feel right. Only because your expectations are that NumPy *be* a MATLAB replacement. The problem is that it sacrifices too much for that to be the case. And we all realize that NumPy needs more stuff added to it to be like IDL/MATLAB such as SciPy, Matplotlib, IPython, etc. Why not then have N.power(2,-2) == 0.24 N.sqrt(-1) == 1j and write a special function that does fast calculation of square-roots for positive values? We've already done this. The special functions are called numpy.power numpy.sqrt (notice that if you do numpy.sqrt(-1+0j) you get the expected answer emphasizing that numpy does no argument checking to determine the output). The intuitive functions (which must do argument checking) are (in numpy.lib.scimath) but exported as scipy.power (actually I need to check that one...) scipy.sqrt What could be simpler? ;-) -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
[EMAIL PROTECTED] wrote: On Wed, 11 Oct 2006, Travis Oliphant wrote: On the other hand requiring all calls to numpy.sqrt to go through an argument-checking wrapper is a bad idea as it will slow down other uses. Interestingly, in worst cases numpy.sqrt is approximately ~3 times slower than scipy.sqrt on negative input but ~2 times faster on positive input: In [47]: pos_input = numpy.arange(1,100,0.001) In [48]: %timeit -n 1000 b=numpy.sqrt(pos_input) 1000 loops, best of 3: 4.68 ms per loop In [49]: %timeit -n 1000 b=scipy.sqrt(pos_input) 1000 loops, best of 3: 10 ms per loop This is the one that concerns me. Slowing everybody down who knows they have positive values just for people that don't seems problematic. In [50]: neg_input = -pos_input In [52]: %timeit -n 1000 b=numpy.sqrt(neg_input) 1000 loops, best of 3: 99.3 ms per loop In [53]: %timeit -n 1000 b=scipy.sqrt(neg_input) 1000 loops, best of 3: 29.2 ms per loop nan's are making things really slow, Yeah, they do. This actually makes the case for masked arrays, rather than using NAN's. -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On Wed, 11 Oct 2006, Travis Oliphant wrote: Interestingly, in worst cases numpy.sqrt is approximately ~3 times slower than scipy.sqrt on negative input but ~2 times faster on positive input: In [47]: pos_input = numpy.arange(1,100,0.001) In [48]: %timeit -n 1000 b=numpy.sqrt(pos_input) 1000 loops, best of 3: 4.68 ms per loop In [49]: %timeit -n 1000 b=scipy.sqrt(pos_input) 1000 loops, best of 3: 10 ms per loop This is the one that concerns me. Slowing everybody down who knows they have positive values just for people that don't seems problematic. I think the code in scipy.sqrt can be optimized from def _fix_real_lt_zero(x): x = asarray(x) if any(isreal(x) (x0)): x = _tocomplex(x) return x def sqrt(x): x = _fix_real_lt_zero(x) return nx.sqrt(x) to (untested) def _fix_real_lt_zero(x): x = asarray(x) if not isinstance(x,(nt.csingle,nt.cdouble)) and any(x0): x = _tocomplex(x) return x def sqrt(x): x = _fix_real_lt_zero(x) return nx.sqrt(x) or def sqrt(x): old = nx.seterr(invalid='raises') try: r = nx.sqrt(x) except FloatingPointError: x = _tocomplex(x) r = nx.sqrt(x) nx.seterr(**old) return r I haven't timed these cases yet.. Pearu - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Tim Hochberg wrote: With python 2.5 out now, perhaps it's time to come up with a with statement context manager. Something like: from __future__ import with_statement import numpy class errstate(object): def __init__(self, **kwargs): self.kwargs = kwargs def __enter__(self): self.oldstate = numpy.seterr(**self.kwargs) def __exit__(self, *exc_info): numpy.seterr(**self.oldstate) a = numpy.arange(10) a/a # ignores divide by zero with errstate(divide='raise'): a/a # raise exception on divide by zer # Would ignore divide by zero again if we got here. -tim This looks great. I think most people aren't aware of the with statement and what it can do (I'm only aware because of your posts, for example). So, what needs to be added to your example in order to just add it to numpy? -Travis - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
nan's are making things really slow, Yeah, they do. This actually makes the case for masked arrays, rather than using NAN's. Travis, Talking about masked arrays, I'm about being done rewriting numpy.core.ma, mainly transforming MaskedArray as a subclass of ndarray (it should be OK by the end of the week), and allowing for an easy subclassing of MaskedArrays (which is far from being the case right now) What would be the best procedure to submit it ? Ticket on SVN ? Wiki on scipy.org ? Thanks again for your time ! Pierre - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On Wed, Oct 11, 2006 at 05:21:44PM -0600, Travis Oliphant wrote: Stefan van der Walt wrote: I agree with Fernando on this one. Further, if I understand correctly, changing sqrt and power to give the right answer by default will slow things down somewhat. But is it worth sacrificing intuitive usage for speed? For NumPy, yes. This is one reason that NumPy by itself is not a MATLAB replacement. Intuitive usage is hopefully not a MATLAB-only feature. N.power(2,-2) == 0 and N.sqrt(-1) == nan just doesn't feel right. Only because your expectations are that NumPy *be* a MATLAB replacement. The problem is that it sacrifices too much for that to be the case. And we all realize that NumPy needs more stuff added to it to be like IDL/MATLAB such as SciPy, Matplotlib, IPython, etc. I have none such expectations -- I havn't used MATLAB in over 5 years. All I'm saying is that, since the value of the square-root of -1 is not nan and 2^(-2) is not 0, it doesn't surprise me that this behaviour confuses people. The intuitive functions (which must do argument checking) are (in numpy.lib.scimath) but exported as scipy.power (actually I need to check that one...) scipy.sqrt What could be simpler? ;-) I'm sure this is going to come back and haunt us. We have two libraries, one depends on and exposes the API of the other, yet it also overrides some functions with its own behaviour, while keeping the same names. I'll shut up now :) Cheers Stéfan - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 11/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: In SciPy 0.3.x the ufuncs were overloaded by more intelligent versions. A very attractive feature was that sqrt(-1) would yield 1j as in Matlab. Then you can program formulas directly (e.g., roots of a 2nd order polynomial) and the right answer is always achieved. In the Matlab-Python battle in mathematics education, this feature is important. Now in SciPy 0.5.x sqrt(-1) yields nan. A lot of code we have, especially for introductory numerics and physics courses, is now broken. This has already made my colleagues at the University skeptical to Python as this lack of backward compatibility would never happen in Matlab. Another problem related to Numeric and numpy is that in these courses we use ScientificPython several places, which applies Numeric and will continue to do so. You then easily get a mix of numpy and Numeric in scripts, which may cause problems and at least extra overhead. Just converting to numpy in your own scripts isn't enough if you call up libraries using and returning Numeric. I wonder, what are the reasons that numpy.sqrt(-1) returns nan? Could sqrt(-1) made to return 1j again? If not, shouldn't numpy.sqrt(-1) raise a ValueError instead of returning silently nan? What is the desired behaviour of sqrt? Should sqrt always return a complex array, regardless of the type of its input? This will be extremely surprising to many users, whose memory usage suddenly doubles and for whom many functions no longer work the way they're accustomed to. Should it return a complex array only when any entry in its input is negative? This will be even *more* surprising when a negative (perhaps even -0) value appears in their matrix (for example, does a+min(a) yield -0s in the minimal values?) and suddenly it's complex. A ValueError is also surprising, and it forces the user to sanitize her array before taking the square root, instead of whenever convenient. If you want MATLAB behaviour, use only complex arrays. If the problem is backward incompatibility, there's a reason 1.0 hasn't been released yet... A. M. Archibald - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On Wed, Oct 11, 2006 at 08:24:01PM -0400, A. M. Archibald wrote: What is the desired behaviour of sqrt? [...] Should it return a complex array only when any entry in its input is negative? This will be even *more* surprising when a negative (perhaps even -0) value appears in their matrix (for example, does a+min(a) yield -0s in the minimal values?) and suddenly it's complex. Luckily sqrt(-0.) gives -0.0 and not nan ;) Regards Stéfan - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
This is a meta-statement about this argument.We already had it. Repeatedly. Whether you choose it one way or the other, for Numeric the community chose it the way it did for a reason. It is a good reason. It isn't stupid. There were good reasons for the other way. Those reasons weren't stupid. It was a 'choice amongst equals'. Being compatible with some other package is all very nice but it is simply a different choice and the choice was already made 10 years ago. If scipy chose to do this differently then you now have an intractable problem; somebody is going to get screwed. So, next time somebody tells you that some different choice amongst equals should be made for this and that good reason, just say no.This is why having a project leader who is mean like me is better than having a nice guy like Travis. (:- - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant wrote: Tim Hochberg wrote: With python 2.5 out now, perhaps it's time to come up with a with statement context manager. Something like: from __future__ import with_statement import numpy class errstate(object): def __init__(self, **kwargs): self.kwargs = kwargs def __enter__(self): self.oldstate = numpy.seterr(**self.kwargs) def __exit__(self, *exc_info): numpy.seterr(**self.oldstate) a = numpy.arange(10) a/a # ignores divide by zero with errstate(divide='raise'): a/a # raise exception on divide by zer # Would ignore divide by zero again if we got here. -tim This looks great. I think most people aren't aware of the with statement and what it can do (I'm only aware because of your posts, for example). So, what needs to be added to your example in order to just add it to numpy? As far as I know, just testing and documentation -- however testing was so minimal that I may find some other stuff. I'll try to clean it up tomorrow so that I'm a little more confident that it works correctly and I'll send another note out then. -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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Travis Oliphant [EMAIL PROTECTED] wrote: Stefan van der Walt wrote:Further, if I understand correctly, changing sqrt and power to givethe right answer by default will slow things down somewhat.But is itworth sacrificing intuitive usage for speed? For NumPy, yes.This is one reason that NumPy by itself is not a MATLAB replacement.This is not about being a Matlab replacement.This is about correctness.Numpy purports to handle complex numbers. Mathematically, sqrt(-1) is a complex number.Therefore Numpy *must* return a complex number.Speed should not take precedence over correctness. If Numpy doesn't return a complex number then it shouldn't pretend to support complex numbers.Greg-- Linux.Because rebooting is for adding hardware. - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Greg Willden wrote: On 10/11/06, *Travis Oliphant* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stefan van der Walt wrote: Further, if I understand correctly, changing sqrt and power to give the right answer by default will slow things down somewhat. But is it worth sacrificing intuitive usage for speed? For NumPy, yes. This is one reason that NumPy by itself is not a MATLAB replacement. This is not about being a Matlab replacement. This is about correctness. I disagree. NumPy does the correct thing when you realize that sqrt is a function that returns the same type as it's input. The field over-which the operation takes place is defined by the input data-type and not the input values. Either way can be considered correct mathematically. As Paul said it was a design decision not to go searching through the array to determine whether or not there are negative numbers in the array. Of course you can do that if you want and that's what scipy.sqrt does. Numpy purports to handle complex numbers. Mathematically, sqrt(-1) is a complex number. Or, maybe it's undefined if you are in the field of real numbers. It all depends. Therefore Numpy *must* return a complex number. Only if the input is complex. That is a reasonable alternative to your specification. If Numpy doesn't return a complex number then it shouldn't pretend to support complex numbers. Of course it supports complex numbers, it just doesn't support automatic conversion to complex numbers.It supports complex numbers the same way Python supports them (i.e. you have to use cmath to get sqrt(-1) == 1j) People can look at this many ways without calling the other way of looking at it unreasonable. I don't see a pressing need to change this in NumPy, and in fact see many reasons to leave it the way it is. This discussion should move to the scipy list because that is the only place where a change could occur. -Travis. - 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=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
On 10/11/06, Tim Hochberg [EMAIL PROTECTED] wrote: Greg Willden wrote: On 10/11/06, *Travis Oliphant* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Stefan van der Walt wrote: Further, if I understand correctly, changing sqrt and power to give the right answer by default will slow things down somewhat.But is it worth sacrificing intuitive usage for speed? For NumPy, yes. This is one reason that NumPy by itself is not a MATLAB replacement. This is not about being a Matlab replacement. This is about correctness. Numpy purports to handle complex numbers. Mathematically, sqrt(-1) is a complex number.That's vastly oversimplified. If you are working with the reals, thensqrt(-1) is undefined (AKA nan). If you are working in the complex plane, then sqrt(-1) is indeed *a* complex number;And if you are working over the rationals, sqrt(-1) and sqrt(-2) lead to different field extensions ;) Of course, numpy doesn't *have* rationals, so I'm just being cute. snip Personally I think that the default error mode should be tightened up. Then people would only see these sort of things if they really careabout them. Using Python 2.5 and the errstate class I posted earlier:# This is what I like for the default error statenumpy.seterr (invalid='raise', divide='raise', over='raise',under='ignore')I like these choices too. Overflow, division by zero, and sqrt(-x) are usually errors, indicating bad data or programming bugs. Underflowed floats, OTOH, are just really, really small numbers and can be treated as zero. An exception might be if the result is used in division and no error is raised, resulting in a loss of accuracy. If complex results are *expected*, then this should be made explicit by using complex numbers. Numpy allows finegrained control of data types and array ordering, it is a bit closer to the metal than Matlab. This extra control allows greater efficiency, both in speed and in storage, at the cost of a bit more care on the programmers side. Chuck - 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=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
