Re: [Numpy-discussion] proposing a beware of [as]matrix() warning
On Apr 28, 2010, at 4:46 PM, David Warde-Farley wrote: On 2010-04-28, at 2:30 PM, Alan G Isaac wrote: Please let us not have this discussion all over again. Agreed. See my preface to this discussion. My main objection is that it's not easy to explain to a newcomer what the difference precisely is, how they interact, why two of them exist, how they are sort-of-compatible-but-not... The matrix class is very useful for teaching. In economics for example, the use of matrix algebra is widespread, while algebra with arrays that are not matrices is very rare. I can (and do) use NumPy matrices even in undergraduate courses. Would it be acceptable to retain the matrix class but not have it imported in the default namespace, and have to import e.g. numpy.matlib to get at them? If you do not like them, do not use them. The problem isn't really with seasoned users of NumPy not liking them, but rather new users being confused by the presence of (what seems to be) two primitives, array and matrix. Two things tend to happen: a) Example code that expects arrays instead receives matrices. If these aren't cast with asarray(), mayhem ensues at the first sight of *. b) Users of class matrix use a proper function correctly coerces input to ndarray, but returns an ndarray. Users are thus confused that, thinking of the function as a black box, putting matrices 'in' doesn't result in getting matrices 'out'. It doesn't take long to get the hang of if you really sit down and work it through, but it also doesn't take long to go back to MATLAB or whatever else. My interest is in having as few conceptual stumbling stones as possible. c) Complicating the situation further, people try to use functions e.g. from scipy.optimize which expect a 1d array by passing in column or row matrices. Even when coerced to array, these have the wrong rank and you get unexpected results (you could argue that we should instead use asarray(..).squeeze() on all incoming arguments, but this may not generalize well). PS There is one change I would not mind: let A * M be undefined if A is an ndarray and M is a NumPy matrix. What about the other binary ops? I would say, matrix goes with matrix, array with array, never the two shall meet unless you explicitly coerce. The ability to mix the two in a single expression does more harm than good, IMHO. This could be done in NumPy 2.0. I'm +1 on not allowing a mix of the two. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposing a beware of [as]matrix() warning
Alan wrote: There is one change I would not mind: let A * M be undefined if A is an ndarray and M is a NumPy matrix. On 4/28/2010 5:46 PM, David Warde-Farley wrote: What about the other binary ops? I would say, matrix goes with matrix, array with array, never the two shall meet unless you explicitly coerce. The ability to mix the two in a single expression does more harm than good, IMHO. I would be fine with this. I mentioned ``*`` explicitly, because it is the dangerous one (most likely to cause surprises). Since M.A gives the array representation of the matrix M, explicit coercion is almost costless. Alan Isaac PS Just to be clear, I'm just a user ... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposing a beware of [as]matrix() warning
On 4/28/2010 5:46 PM, David Warde-Farley wrote: Would it be acceptable to retain the matrix class but not have it imported in the default namespace, and have to import e.g. numpy.matlib to get at them? If we can have A * M undefined, then I do not think this is a needed addition. But I do not have a strong opinion. It does not create a significant barrier in teaching (and might even have some advantages). Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndimage.label - howto force SWIG to use int32 - even on 64bit Linux ?
Thanks for those replies.
But isn't npy_intp about pointers ?
I would need something likenpy_int32 .
But does that exist ? Where is the list of types that numpy.i supports ?
Also, BTW, is there code duplication if numpy.i supports (let's say)
both npy_int and npy_int32 on a machine, where int is already 32
bits by default !? (I'm talking about the size of the resulting object
file, I guess...)
Thanks again for your help,
Sebastian
On Wed, Apr 28, 2010 at 11:51 PM, Bill Spotz wfsp...@sandia.gov wrote:
Both types of typemaps are enabled, so you just need to do you %apply
directives correctly:
%apply (npy_intp* IN_ARRAY1, int DIM1) {(npy_intp* seq, int n)};
etc
SWIG should be able to figure it out from there.
On Apr 28, 2010, at 12:58 PM, Charles R Harris wrote:
On Tue, Apr 27, 2010 at 2:27 AM, Sebastian Haase
seb.ha...@gmail.com wrote:
Hi,
I wanted to write some C code to accept labels as they come from
ndimage.label.
For some reason ndimage.label produces its output as an int32 array -
even on my 64bit system .
BTW, could this be considered a bug ?
Likely.
Now, if I use the typemaps of numpy.i I can choose between NPY_LONG
and NPY_INT.
But those are sometimes 32 sometimes 64 bit, depending on the system.
Any ideas ... ?
npy_intp.
Chuck
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-0154 **
** Albuquerque, NM 87185-0370 Email: wfsp...@sandia.gov **
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposing a beware of [as]matrix() warning
Alan G Isaac wrote: On 4/28/2010 12:08 PM, Dag Sverre Seljebotn wrote: it would be good to deprecate the matrix class from NumPy Please let us not have this discussion all over again. The matrix class is very useful for teaching. In economics for example, the use of matrix algebra is widespread, while algebra with arrays that are not matrices is very rare. I can (and do) use NumPy matrices even in undergraduate courses. If you do not like them, do not use them. If you want `matrix` replaced with a better matrix object, offer a replacement for community consideration. Point taken, I'm sorry. (If or when my own matrix linear algebra code matures I'll open source it for sure, but it's not there yet, and I don't believe it will fit within NumPy.) Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] put with increment ?
Hello everyone, Is there a 'numpy' efficient way to do the following loop: for i, v in indices, values: total[ i ] += v The behaviour is like numpy.put, but instead of overwriting the array element, it is incremented. Currently I have a little C extension which does the job, but I'm lazy to fix it up for all the various dtypes etc. Am I missing a more general way? I have repeated values in indices, so that: total[indices]+=values ... does not give the result I'm after. Thanks Jon ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] put with increment ?
On Thu, Apr 29, 2010 at 03:28, Jon Wright wri...@esrf.fr wrote: Hello everyone, Is there a 'numpy' efficient way to do the following loop: for i, v in indices, values: total[ i ] += v The behaviour is like numpy.put, but instead of overwriting the array element, it is incremented. Currently I have a little C extension which does the job, but I'm lazy to fix it up for all the various dtypes etc. Am I missing a more general way? total = np.bincount(indices, values) -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What should be the value of nansum of nan's?
On Wed, Apr 28, 2010 at 11:56 AM, T J tjhn...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:03 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, We need to make a decision for ticket #1123 regarding what nansum should return when all values are nan. At some earlier point it was zero, but currently it is nan, in fact it is nan whatever the operation is. That is consistent, simple and serves to mark the array or axis as containing all nans. I would like to close the ticket and am a bit inclined to go with the current behaviour although there is an argument to be made for returning 0 for the nansum case. Thoughts? To add a bit of context, one could argue that the results should be consistent with the equivalent operations on empty arrays and always be non-nan. In [1]: nansum([]) Out[1]: nan In [2]: sum([]) Out[2]: 0.0 This seems like an obvious one to me. What is the spirit of nansum? Return the sum of array elements over a given axis treating Not a Numbers (NaNs) as zero. Okay. So NaNs in an array are treated as zeros and the sum is performed as one normally would perform it starting with an initial sum of zero. So if all values are NaN, then we add nothing to our original sum and still return 0. I'm not sure I understand the argument that it should return NaN. It is counter to the *purpose* of nansum. Also, if one wants to determine if all values in an array are NaN, isn't there another way? Let's keep (or make) those distinct operations, as they are definitely distinct concepts. __ It looks like the consensus is that zero should be returned. This is a change from current behaviour and that bothers me a bit. Here are some other oddities In [6]: nanmax([nan]) Out[6]: nan In [7]: nanargmax([nan]) Out[7]: nan In [8]: nanargmax([1]) Out[8]: 0 So it looks like the current behaviour is very much tilted towards nans as missing data flags. I think we should just leave that as is with perhaps a note in the docs to that effect. The decision here should probably accommodate the current users of these functions, of which I am not one. If we leave the current behaviour as is then I think the rest of the nan functions need fixes to return nan for empty sequences as nansum is the only one that currently does that. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Adding an ndarray.dot method
Wed, 28 Apr 2010 14:12:07 -0400, Alan G Isaac wrote: [clip] Here is a related ticket that proposes a more explicit alternative: adding a ``dot`` method to ndarray. http://projects.scipy.org/numpy/ticket/1456 I kind of like this idea. Simple, obvious, and leads to clear code: a.dot(b).dot(c) or in another multiplication order, a.dot(b.dot(c)) And here's an implementation: http://github.com/pv/numpy-work/commit/414429ce0bb0c4b7e780c4078c5ff71c113050b6 I think I'm going to apply this, unless someone complains, as I don't see any downsides (except maybe adding one more to the huge list of methods ndarray already has). Cheers, Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy compilation error
Hi, I have a few questions: 1) I downloaded numpy1.3.0 and installed it in a directory using the command *python setup.py install --prefix=$HOME/src/numpy *and I see that numpy files have been generated in that directory. Now when I tried to install matplotlib, it complained that my numpy version is 1.0.3. When I go in python mode on command line I get the following output: *[prad...@scaramanga ~]$python Python 2.4.4 (#1, Oct 23 2006, 13:58:00) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type help, copyright, credits or license for more information. import numpy print numpy.__version__ 1.0.3 * 2) I donwloaded Scipy.0.7.2 from http://sourceforge.net/projects/scipy/files/ I installed it using *python setup.py install --prefix=$HOME/src/scipy * Again when I goto command line python, I get the following output *[prad...@scaramanga ~]$python Python 2.4.4 (#1, Oct 23 2006, 13:58:00) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type help, copyright, credits or license for more information. import scipy /usr/lib/python2.4/site-packages/scipy/misc/__init__.py:25: DeprecationWarning: ScipyTest is now called NumpyTest; please update your code test = ScipyTest().test * Why isn't my python reading things from the newer installed versions? Thanks PRadeep 2010/4/21 David Cournapeau courn...@gmail.com On Thu, Apr 22, 2010 at 2:23 AM, Christopher Barker chris.bar...@noaa.gov wrote: I hadn't read the thread carefully enough to realize that the OP was asking about a non-root install, but in any case, I'd still encourage that folks set ONE standard place in their PYTHONPATH, rather than one for each package, and make sure you're careful about running more than one version of Python. The beauty of --user is that you don't need PYTHONPATH, and it is interpreter specific (at least if the package is correctly done). PYTHONPATH is becoming a pain with python 3.* cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndimage.label - howto force SWIG to use int32 - even on 64bit Linux ?
On Thu, Apr 29, 2010 at 1:52 AM, Sebastian Haase seb.ha...@gmail.comwrote: Thanks for those replies. But isn't npy_intp about pointers ? At one point perhaps, but how it is used is to get 32 bits on 32 OS's and 64 bits on 64 bit OS's, For the common architectures int will always be 32 bits regardless, it is the long type that moves around depending on both bits and os. I would need something likenpy_int32 . But does that exist ? Where is the list of types that numpy.i supports ? Also, BTW, is there code duplication if numpy.i supports (let's say) both npy_int and npy_int32 on a machine, where int is already 32 bits by default !? (I'm talking about the size of the resulting object file, I guess...) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding an ndarray.dot method
Hi, I kind of like this idea. Simple, obvious, and leads to clear code: a.dot(b).dot(c) or in another multiplication order, a.dot(b.dot(c)) And here's an implementation: http://github.com/pv/numpy-work/commit/414429ce0bb0c4b7e780c4078c5ff71c113050b6 I think I'm going to apply this, unless someone complains, as I don't see any downsides (except maybe adding one more to the huge list of methods ndarray already has). Excellent excellent excellent. Once again, I owe you a beverage of your choice. Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding an ndarray.dot method
On Apr 29, 2010, at 2:30 PM, Pauli Virtanen wrote: Wed, 28 Apr 2010 14:12:07 -0400, Alan G Isaac wrote: [clip] Here is a related ticket that proposes a more explicit alternative: adding a ``dot`` method to ndarray. http://projects.scipy.org/numpy/ticket/1456 I kind of like this idea. Simple, obvious, and leads to clear code: a.dot(b).dot(c) or in another multiplication order, a.dot(b.dot(c)) And here's an implementation: http://github.com/pv/numpy-work/commit/414429ce0bb0c4b7e780c4078c5ff71c113050b6 I think I'm going to apply this, unless someone complains, as I don't see any downsides (except maybe adding one more to the huge list of methods ndarray already has). +1 -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What should be the value of nansum of nan's?
On Thu, Apr 29, 2010 at 12:56 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Apr 28, 2010 at 11:56 AM, T J tjhn...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:03 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, We need to make a decision for ticket #1123 regarding what nansum should return when all values are nan. At some earlier point it was zero, but currently it is nan, in fact it is nan whatever the operation is. That is consistent, simple and serves to mark the array or axis as containing all nans. I would like to close the ticket and am a bit inclined to go with the current behaviour although there is an argument to be made for returning 0 for the nansum case. Thoughts? To add a bit of context, one could argue that the results should be consistent with the equivalent operations on empty arrays and always be non-nan. In [1]: nansum([]) Out[1]: nan In [2]: sum([]) Out[2]: 0.0 This seems like an obvious one to me. What is the spirit of nansum? Return the sum of array elements over a given axis treating Not a Numbers (NaNs) as zero. Okay. So NaNs in an array are treated as zeros and the sum is performed as one normally would perform it starting with an initial sum of zero. So if all values are NaN, then we add nothing to our original sum and still return 0. I'm not sure I understand the argument that it should return NaN. It is counter to the *purpose* of nansum. Also, if one wants to determine if all values in an array are NaN, isn't there another way? Let's keep (or make) those distinct operations, as they are definitely distinct concepts. __ It looks like the consensus is that zero should be returned. This is a change from current behaviour and that bothers me a bit. Here are some other oddities In [6]: nanmax([nan]) Out[6]: nan In [7]: nanargmax([nan]) Out[7]: nan In [8]: nanargmax([1]) Out[8]: 0 So it looks like the current behaviour is very much tilted towards nans as missing data flags. I think we should just leave that as is with perhaps a note in the docs to that effect. The decision here should probably accommodate the current users of these functions, of which I am not one. If we leave the current behaviour as is then I think the rest of the nan functions need fixes to return nan for empty sequences as nansum is the only one that currently does that. I disagree, I really would like to get nansum([Nan]) to be zero max, min don't have a neutral element, only sum and prod have it (and cumsum and cumprod and maybe others), so in this case nan is the obvious answer (besides an exception): np.max([]) Traceback (most recent call last): File pyshell#124, line 1, in module np.max([]) File C:\Programs\Python25\lib\site-packages\numpy\core\fromnumeric.py, line 1765, in amax return _wrapit(a, 'max', axis, out) File C:\Programs\Python25\lib\site-packages\numpy\core\fromnumeric.py, line 37, in _wrapit result = getattr(asarray(obj),method)(*args, **kwds) ValueError: zero-size array to ufunc.reduce without identity np.argmax([]) Traceback (most recent call last): File pyshell#125, line 1, in module np.argmax([]) File C:\Programs\Python25\lib\site-packages\numpy\core\fromnumeric.py, line 717, in argmax return _wrapit(a, 'argmax', axis) File C:\Programs\Python25\lib\site-packages\numpy\core\fromnumeric.py, line 37, in _wrapit result = getattr(asarray(obj),method)(*args, **kwds) ValueError: attempt to get argmax/argmin of an empty sequence min([]) Traceback (most recent call last): File pyshell#126, line 1, in module min([]) ValueError: min() arg is an empty sequence max([]) Traceback (most recent call last): File pyshell#127, line 1, in module max([]) ValueError: max() arg is an empty sequence Josef Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] What should be the value of nansum of nan's?
On Thu, Apr 29, 2010 at 9:56 AM, Charles R Harris charlesr.har...@gmail.com wrote: It looks like the consensus is that zero should be returned. This is a change from current behaviour and that bothers me a bit. Here are some other oddities In [6]: nanmax([nan]) Out[6]: nan In [7]: nanargmax([nan]) Out[7]: nan In [8]: nanargmax([1]) Out[8]: 0 So it looks like the current behaviour is very much tilted towards nans as missing data flags. I think we should just leave that as is with perhaps a note in the docs to that effect. The decision here should probably accommodate the current users of these functions, of which I am not one. That works well for me. If we leave the current behaviour as is then I think the rest of the nan functions need fixes to return nan for empty sequences as nansum is the only one that currently does that. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding an ndarray.dot method
On Thu, Apr 29, 2010 at 1:30 PM, Pauli Virtanen p...@iki.fi wrote: Wed, 28 Apr 2010 14:12:07 -0400, Alan G Isaac wrote: [clip] Here is a related ticket that proposes a more explicit alternative: adding a ``dot`` method to ndarray. http://projects.scipy.org/numpy/ticket/1456 I kind of like this idea. Simple, obvious, and leads to clear code: a.dot(b).dot(c) or in another multiplication order, a.dot(b.dot(c)) And here's an implementation: http://github.com/pv/numpy-work/commit/414429ce0bb0c4b7e780c4078c5ff71c113050b6 I think I'm going to apply this, unless someone complains, as I don't see any downsides (except maybe adding one more to the huge list of methods ndarray already has). Hey, that was my weekend project 8-) But obviously I think it is a good idea. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
