Re: [Numpy-discussion] PyPy guys deserve some help on micronumpy from you, numpy gurus!
On Thu, Sep 15, 2011 at 11:34 AM, Peter numpy-discuss...@maubp.freeserve.co.uk wrote: This may not be the best place to ask, but how should a python script (e.g. setup.py) distinguish between real NumPy and micronumpy? Or should I instead be looking to distinguish PyPy versus another Python implementation? For anyone interested, over on the pypy-dev list Alex recommended: import platform; platform.python_implementation == 'PyPy' http://mail.python.org/pipermail/pypy-dev/2011-September/008315.html Peter ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Difficulty using special types like timedelta and Decimal
Certain numerical types in Python that support accurate fractional calculations such as timedelta and Decimal do not allow for multiplication or division by a floating point number, but do allow for use with an integer. This can cause difficulties with some functions such as np.gradient() which has a division by 2.0 as part of the algorithm. My question is: with Py3k's division always resulting in a floating point result regardless of the denominator's type, would it be possible to change some of these common denominators over to integers in order to better facilitate support for these special types? Obviously, I don't think we could expect full support of these types, but maybe a mechanism could be developed to better handle these? Thanks, Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Indexing by label in 3rd dimension
Hello list! I have an array *mask* of shape (a, b) and another array *intensities* of shape (N, a, b), where the values in *mask* range from 0 to N-1. It is somehow similar to label arrays in scipy.ndimage. Now I want to pick those entries from the first dimension of *intensities* which are given by *mask*. The returned array shall again wave shape (a, b). Can this be done with fancy indexing? Thank you, Ben ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Indexing by label in 3rd dimension
On Friday, September 16, 2011, Benjamin Landenberger benjamin.landenber...@imtek.uni-freiburg.de wrote: Hello list! I have an array *mask* of shape (a, b) and another array *intensities* of shape (N, a, b), where the values in *mask* range from 0 to N-1. It is somehow similar to label arrays in scipy.ndimage. Now I want to pick those entries from the first dimension of *intensities* which are given by *mask*. The returned array shall again wave shape (a, b). Can this be done with fancy indexing? Thank you, Ben Try intensities[mask, xrange(a), xrange(b)]. Untested, but it would work for 1d, haven't tried for 2d. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Indexing by label in 3rd dimension
On Friday, September 16, 2011, Benjamin Root ben.r...@ou.edu wrote: On Friday, September 16, 2011, Benjamin Landenberger benjamin.landenber...@imtek.uni-freiburg.de wrote: Hello list! I have an array *mask* of shape (a, b) and another array *intensities* of shape (N, a, b), where the values in *mask* range from 0 to N-1. It is somehow similar to label arrays in scipy.ndimage. Now I want to pick those entries from the first dimension of *intensities* which are given by *mask*. The returned array shall again wave shape (a, b). Can this be done with fancy indexing? Thank you, Ben Try intensities[mask, xrange(a), xrange(b)]. Untested, but it would work for 1d, haven't tried for 2d. Ben Root Crap, that wouldn't work... Sorry. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Indexing by label in 3rd dimension
On Fri, Sep 16, 2011 at 10:18 AM, Benjamin Landenberger benjamin.landenber...@imtek.uni-freiburg.de wrote: Hello list! I have an array *mask* of shape (a, b) and another array *intensities* of shape (N, a, b), where the values in *mask* range from 0 to N-1. It is somehow similar to label arrays in scipy.ndimage. Now I want to pick those entries from the first dimension of *intensities* which are given by *mask*. The returned array shall again wave shape (a, b). Can this be done with fancy indexing? The choose() function can be used: In [19]: intensities Out[19]: array([[[ 1, 2, 3], [ 4, 5, 6], [ 7, 8, 9]], [[11, 12, 13], [14, 15, 16], [17, 18, 19]], [[21, 22, 23], [24, 25, 26], [27, 28, 29]]]) In [20]: mask Out[20]: array([[0, 0, 1], [1, 1, 1], [1, 2, 2]]) In [21]: choose(mask, intensities) Out[21]: array([[ 1, 2, 13], [14, 15, 16], [17, 28, 29]]) Warren Thank you, Ben ___ 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] Difficulty using special types like timedelta and Decimal
On Fri, Sep 16, 2011 at 9:11 AM, Benjamin Root ben.r...@ou.edu wrote: Certain numerical types in Python that support accurate fractional calculations such as timedelta and Decimal do not allow for multiplication or division by a floating point number, but do allow for use with an integer. This can cause difficulties with some functions such as np.gradient() which has a division by 2.0 as part of the algorithm. My question is: with Py3k's division always resulting in a floating point result regardless of the denominator's type, would it be possible to change some of these common denominators over to integers in order to better facilitate support for these special types? Obviously, I don't think we could expect full support of these types, but maybe a mechanism could be developed to better handle these? Timedelta seems to work in master: In [1]: timedelta64(5) Out[1]: numpy.timedelta64(5) In [2]: timedelta64(5)/2.0 Out[2]: numpy.timedelta64(2) In [3]: timedelta64(5)/2 Out[3]: numpy.timedelta64(2) I think making the change to 2 is a reasonable thing to do, but you should put a from __future__ import division at the beginning of the module containing gradient and make sure everything still works. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Difficulty using special types like timedelta and Decimal
On Friday, September 16, 2011, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Sep 16, 2011 at 9:11 AM, Benjamin Root ben.r...@ou.edu wrote: Certain numerical types in Python that support accurate fractional calculations such as timedelta and Decimal do not allow for multiplication or division by a floating point number, but do allow for use with an integer. This can cause difficulties with some functions such as np.gradient() which has a division by 2.0 as part of the algorithm. My question is: with Py3k's division always resulting in a floating point result regardless of the denominator's type, would it be possible to change some of these common denominators over to integers in order to better facilitate support for these special types? Obviously, I don't think we could expect full support of these types, but maybe a mechanism could be developed to better handle these? Timedelta seems to work in master: In [1]: timedelta64(5) Out[1]: numpy.timedelta64(5) In [2]: timedelta64(5)/2.0 Out[2]: numpy.timedelta64(2) In [3]: timedelta64(5)/2 Out[3]: numpy.timedelta64(2) I think making the change to 2 is a reasonable thing to do, but you should put a from __future__ import division at the beginning of the module containing gradient and make sure everything still works. Chuck I am referring to a numpy array of python timedeltas, not numpy's. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Difficulty using special types like timedelta and Decimal
On Fri, Sep 16, 2011 at 11:35 AM, Benjamin Root ben.r...@ou.edu wrote: On Friday, September 16, 2011, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Sep 16, 2011 at 9:11 AM, Benjamin Root ben.r...@ou.edu wrote: Certain numerical types in Python that support accurate fractional calculations such as timedelta and Decimal do not allow for multiplication or division by a floating point number, but do allow for use with an integer. This can cause difficulties with some functions such as np.gradient() which has a division by 2.0 as part of the algorithm. My question is: with Py3k's division always resulting in a floating point result regardless of the denominator's type, would it be possible to change some of these common denominators over to integers in order to better facilitate support for these special types? Obviously, I don't think we could expect full support of these types, but maybe a mechanism could be developed to better handle these? Timedelta seems to work in master: In [1]: timedelta64(5) Out[1]: numpy.timedelta64(5) In [2]: timedelta64(5)/2.0 Out[2]: numpy.timedelta64(2) In [3]: timedelta64(5)/2 Out[3]: numpy.timedelta64(2) I think making the change to 2 is a reasonable thing to do, but you should put a from __future__ import division at the beginning of the module containing gradient and make sure everything still works. Chuck I am referring to a numpy array of python timedeltas, not numpy's. Ben Root A couple of additional bugs I have encountered with np.gradient(). First, the documentation says that the input data can be array-like, yet the first line of the function calls the shape() method (and later uses the dtype() method). Second, there is a check in the code that sees if the input array is not 'd', 'f', 'D', or 'F'. If it isn't one of those, then it forces the output type to be 'd'. I am not entirely sure I understand the reasoning here, but at the very least, if I pass in an object array, wouldn't it be expected that I get an object array back? As an interesting sidenote, usually, one would expect the same type going in as going out, however, with python datetime objects, datetime goes in and timedeltas come out in functions like np.diff() and (theoretically) np.gradient(). Don't know how much that would impact the prospect of supporting python datetime and/or timedelta objects, but I thought I should mention that. Furthermore, in light of the recent addition of datetime to numpy itself, maybe we ought to consider an automatic coercion of a list of python datetime/timedelta objects into a numpy array of the numpy equivalents? We do this right now with lists of floats and integers. Just a thought. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [ANN] glumpy 0.2.0
Hi folks, I am pleased to announce a new release of glumpy, a small python library for the (very) fast vizualization of numpy arrays, (mainly two dimensional) that has been designed with efficiency in mind. If you want to draw nice figures for inclusion in a scientific article, you’d better use matplotlib but if you want to have a sense of what’s going on in your simulation while it is running, then maybe glumpy can help you. Download and screenshots at: http://code.google.com/p/glumpy/ Nicolas___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] glumpy 0.2.0
Hi Nicolas, that looks great. Could you make this available such that `pip install glumpy` would work? cheers, Samuel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] type-casting inconsistency with timedelta64
Came across an oddity when experimenting with the datetime64 and timedelta64
objects.
a = np.zeros((10,), dtype='l')
b = np.datetime64('2010-12-20T14:23:56-0600')
c = np.datetime64('2010-12-20T21:27:09-0600')
a[0:1] = c - b # This works fine
a[0] = c - b # This does not
The second assignment throws the following error:
TypeError: don't know how to convert scalar number to long
Cheers,
Ben Root
P.S. - np.arange() can make ranges of datetime64 from string inputs, but
np.linspace() can not (and does not take a dtype kwarg).
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] type-casting inconsistency with timedelta64
On Fri, Sep 16, 2011 at 2:28 PM, Benjamin Root ben.r...@ou.edu wrote:
Came across an oddity when experimenting with the datetime64 and
timedelta64 objects.
a = np.zeros((10,), dtype='l')
b = np.datetime64('2010-12-20T14:23:56-0600')
c = np.datetime64('2010-12-20T21:27:09-0600')
a[0:1] = c - b # This works fine
a[0] = c - b # This does not
The second assignment throws the following error:
TypeError: don't know how to convert scalar number to long
Certainly inconsistent:
In [8]: (c - b).astype(long)
Out[8]: 25393
In [9]: a[0] = (c - b).astype(long)
works. I don't think either should work without an explicit cast because the
units get lost.
P.S. - np.arange() can make ranges of datetime64 from string inputs, but
np.linspace() can not (and does not take a dtype kwarg).
A dtype keyword would be problematic since linspace needs to have fractions
to do the division. On the other hand, having a convenient way to produce
equally spaced time sounds useful. Hmm...
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
