[Numpy-discussion] Multiplying numpy floats and python lists
I came across some strange behavior when multiplying numpy floats and python lists: the list is returned unchanged: In [18]: np.float64(1.2) * [1, 2] Out[18]: [1, 2] On the other hand, multiplying an array scalar and a python list gives the expected answer In [19]: np.array(1.2) * [1, 2] Out[19]: array([ 1.2, 2.4]) Finally, multiplying a python float and a python list gives an error: In [20]: 1.2 * [1, 2] --- TypeError Traceback (most recent call last) /Users/Tony/ipython console in module() TypeError: can't multiply sequence by non-int of type 'float' These last two results (with the array scalar and the python float) both seem appropriate, but the numpy-float behavior is surprising. Is this a bug? -Tony ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Multiplying numpy floats and python lists
On Jun 20, 2010, at 2:28 PM, Pauli Virtanen wrote: su, 2010-06-20 kello 13:56 -0400, Tony S Yu kirjoitti: I came across some strange behavior when multiplying numpy floats and python lists: the list is returned unchanged: In [18]: np.float64(1.2) * [1, 2] Out[18]: [1, 2] Probably a bug, it seems to round the result first to an integer, and then do the usual Python thing (try for example np.float64(2.2)). I'd suggest filing a bug ticket. Done: http://projects.scipy.org/numpy/ticket/1516 Looking at CPython source code, the issue seems to be that np.float64 for some reason passes PyIndex_Check. But (without whipping out gdb) I can't understand how this can be: the float64 scalar type is not supposed to have a non-NULL in the nb_index slot. Indeed, a np.float64.__index__ method does not exist, and the following indeed does not work: [1, 2, 3][np.float64(2.2)] Strange. -- Pauli Virtanen ___ 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] Bug in nanmin called with unsigned integers
On May 25, 2010, at 10:57 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 8:21 PM, Tony S Yu tsy...@gmail.com wrote: I got bit again by this bug with unsigned integers. (My original changes got overwritten when I updated from svn and, unfortunately, merged conflicts without actually looking over the changes.) In any case, I thought it'd be a good time to bump the issue (with patch). Cheers, -Tony PS: Just for context, this issue comes up when displaying images with Chaco (which converts images to unsigned integer arrays and calls nanmin). Fixed in r8445. Please add some tests. I'm not totally sure what's appropriate to test, so I just added a simple test to the comments for the ticket. On a side note, I noticed that all the nan-ops degenerate to their non-nan-ops counterparts (i.e. nanmin -- min) when called with integer dtypes. Below is a diff where that's made a little more obvious by returning early for integer dtypes. Cheers, -Tony Index: numpy/lib/function_base.py === --- numpy/lib/function_base.py (revision 8445) +++ numpy/lib/function_base.py (working copy) @@ -1295,15 +1295,15 @@ y = array(a, subok=True) -mask = isnan(a) # We only need to take care of NaN's in floating point arrays -if not np.issubdtype(y.dtype, np.integer): -# y[mask] = fill -# We can't use fancy indexing here as it'll mess w/ MaskedArrays -# Instead, let's fill the array directly... -np.putmask(y, mask, fill) - +if np.issubdtype(y.dtype, np.integer): +return op(y, axis=axis) +mask = isnan(a) +# y[mask] = fill +# We can't use fancy indexing here as it'll mess w/ MaskedArrays +# Instead, let's fill the array directly... +np.putmask(y, mask, fill) res = op(y, axis=axis) mask_all_along_axis = mask.all(axis=axis) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Bug in nanmin called with unsigned integers
I got bit again by this bug with unsigned integers. (My original changes got overwritten when I updated from svn and, unfortunately, merged conflicts without actually looking over the changes.) In any case, I thought it'd be a good time to bump the issue (with patch). Cheers, -Tony PS: Just for context, this issue comes up when displaying images with Chaco (which converts images to unsigned integer arrays and calls nanmin). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] OverflowError using _nanop with unsigned integers
Hi, Functions that call _nanop (i.e. nan[arg]min, nan[arg]max) currently fail with unsigned integers. For example: np.nanmin(np.array([0, 1], dtype=np.uint8)) OverflowError: cannot convert float infinity to integer It seems that unsigned integers don't get identified as integers in the _nanop function. Checking against `np.integer` instead of the built-in `int` will catch signed and unsigned integers, as shown below. Cheers, -Tony Note: the diff below also contains a change I made to fix ticket #1177 Index: numpy/lib/function_base.py === --- numpy/lib/function_base.py (revision 7749) +++ numpy/lib/function_base.py (working copy) @@ -1038,6 +1038,8 @@ if isinstance(x, (float, int, number)): return compiled_interp([x], xp, fp, left, right).item() +elif isinstance(x, np.ndarray) and x.ndim == 0: +return compiled_interp(x[np.newaxis], xp, fp, left, right)[0] else: return compiled_interp(x, xp, fp, left, right) @@ -1349,7 +1351,7 @@ mask = isnan(a) # We only need to take care of NaN's in floating point arrays -if not np.issubdtype(y.dtype, int): +if not np.issubdtype(y.dtype, np.integer): y[mask] = fill res = op(y, axis=axis) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Setting a firm release date for 1st december.
On Nov 2, 2009, at 11:09 AM, numpy-discussion-requ...@scipy.org wrote: From: David Cournapeau courn...@gmail.com Subject: [Numpy-discussion] 1.4.0: Setting a firm release date for 1st december. To: Discussion of Numerical Python numpy-discussion@scipy.org Message-ID: 5b8d13220911020029q1d9f1bd7ia1770e3b93e6e...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hi, I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any Otherwise, I think there has been quite a lot of new features. If people want to add new functionalities or features, please do it soon, cheers, David This seems like an appropriate opportunity to ping an issue I posted on Trac: http://projects.scipy.org/numpy/ticket/1177 Basically, interp doesn't currently play nice with numpy scalars. Patch included with ticket (see second comment). Cheers, -Tony___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Weird clipping when astype(int) used on large numbers
I ran into this weird behavior with astype(int) In [57]: a = np.array(1E13) In [58]: a.astype(int) Out[58]: array(-2147483648) I understand why large numbers need to be clipped when converting to int (although I would have expected some sort of warning), but I'm puzzled by the negative value. Shouldn't the above code clip the value to the max positive int (2147483647)... and maybe issue a warning? Thanks, -Tony P.S. In case this is a problem with my install: OS X 10.5.5 Python 2.5.1 Numpy 1.2.0 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Traceback on divide by zero error
On Dec 13, 2007, at 2:21 PM, Robert Kern wrote: Tony S Yu wrote: Hello, This is something that's been bothering for awhile. When numpy raises the following divide by zero error: Warning: divide by zero encountered in double_scalars is there a way to get a Traceback on where that warning occurred. In [1]: from numpy import * In [3]: seterr(divide='raise') seterr(divide='warn') is exactly what I was looking for. Thanks! -Tony ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
