[Numpy-discussion] non-intuitive behaviour in numpy.array([list], numpy.object_)
When constructing an numpy object array from a list of numpy arrays, one observes the following behaviour import numpy as N a=[N.zeros([2,2], N.object_), N.zeros([2,2], N.object_)] b=N.array(a, N.object_) print b.shape (2, 2, 2) a=[N.zeros([2,2], N.object_), N.zeros([2,1], N.object_)] b=N.array(a, N.object_) print b.shape (2,) I understand that this is because in the 1st instance, numpy is trying to be clever and recognises that the list of arrays a can be reshaped into a 3-d array. But surely, if we are constructing an array with the object_ dtype, the first should also be converted into a shape (2,) array? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] non-intuitive behaviour in numpy.array([list], numpy.object_)
Garnet Chan wrote: When constructing an numpy object array from a list of numpy arrays, one observes the following behaviour import numpy as N a=[N.zeros([2,2], N.object_), N.zeros([2,2], N.object_)] b=N.array(a, N.object_) print b.shape (2, 2, 2) a=[N.zeros([2,2], N.object_), N.zeros([2,1], N.object_)] b=N.array(a, N.object_) print b.shape (2,) I understand that this is because in the 1st instance, numpy is trying to be clever and recognises that the list of arrays a can be reshaped into a 3-d array. But surely, if we are constructing an array with the object_ dtype, the first should also be converted into a shape (2,) array? arrays of the _object dtype are plain weird -- as arbitrary objects can be sequences (and mutable ones at that!), it's impossible to automatically create the shape of arrays of objects that the user wants. Perhaps it could be a bit smarter to be more consistent, but what you really need to do is define the shape for numpy, and not expect it to figure out what you want -- even if it does the right thing with one example. If you want a (2,) array, then do this: b = N.empty(2, dtype=N.object) b[:]=a b.shape (2,) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Apologies if I've missed the discussion of this, but I was recently surprised by the following behavior (in svn trunk 4673). The following code runs without triggering the assertion. import numpy as np print np.__version__ a=np.int32(42) b=np.array([],dtype=np.int32) assert np.allclose(a,b) Is this expected behavior of numpy or is this a bug I should report? Thanks, Andrew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Andrew Straw wrote: Apologies if I've missed the discussion of this, but I was recently surprised by the following behavior (in svn trunk 4673). The following code runs without triggering the assertion. import numpy as np print np.__version__ a=np.int32(42) b=np.array([],dtype=np.int32) assert np.allclose(a,b) Is this expected behavior of numpy or is this a bug I should report? Bug, I think. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Jan 3, 2008 1:06 PM, Robert Kern [EMAIL PROTECTED] wrote: Andrew Straw wrote: Apologies if I've missed the discussion of this, but I was recently surprised by the following behavior (in svn trunk 4673). The following code runs without triggering the assertion. import numpy as np print np.__version__ a=np.int32(42) b=np.array([],dtype=np.int32) assert np.allclose(a,b) Is this expected behavior of numpy or is this a bug I should report? Bug, I think. Isn't it trivially true that all elements of an empty array are close to any number? For instance, it is a well known fact that all blue, cheese eating martians speak esperanto. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] non-intuitive behaviour in numpy.array([list], numpy.object_)
Thanks - that's clear I guess, although I still think that it might be less confusing if numpy did not try to be clever! On 1/3/08, Christopher Barker [EMAIL PROTECTED] wrote: Garnet Chan wrote: When constructing an numpy object array from a list of numpy arrays, one observes the following behaviour import numpy as N a=[N.zeros([2,2], N.object_), N.zeros([2,2], N.object_)] b=N.array(a, N.object_) print b.shape (2, 2, 2) a=[N.zeros([2,2], N.object_), N.zeros([2,1], N.object_)] b=N.array(a, N.object_) print b.shape (2,) I understand that this is because in the 1st instance, numpy is trying to be clever and recognises that the list of arrays a can be reshaped into a 3-d array. But surely, if we are constructing an array with the object_ dtype, the first should also be converted into a shape (2,) array? arrays of the _object dtype are plain weird -- as arbitrary objects can be sequences (and mutable ones at that!), it's impossible to automatically create the shape of arrays of objects that the user wants. Perhaps it could be a bit smarter to be more consistent, but what you really need to do is define the shape for numpy, and not expect it to figure out what you want -- even if it does the right thing with one example. If you want a (2,) array, then do this: b = N.empty(2, dtype=N.object) b[:]=a b.shape (2,) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] MaskedArray and Record Arrays
I am experimenting with the new MaskedArray (from
http://svn.scipy.org/svn/numpy/branches/maskedarray) as a
replacement for my own home-brewed masked data handling mechanisms. In
what I have built myself, I often work with record arrays that have a
single mask for the whole record (no fieldmask). It seems like it is
almost possible to do this with MaskedArray:
a = masked_array(
... [(1,10,100),(0,0,0),(2,20,200)],
... mask=[False,True,False],
... dtype=[('x',float), ('y',float), ('c',int)]
... )
masked_array(data = [(1.0, 10.0, 100) -- (2.0, 20.0, 200)],
mask = [False True False],
fill_value=???)
except MaskedArray.__getitem__ doesn't check to see if I'm asking for
a field instead of an index:
a['x']
Traceback (most recent call last):
File stdin, line 1, in module
File qlab\ma\core.py, line 1269, in __getitem__
dout._mask = ndarray.__getitem__(m, indx).reshape(dout.shape)
ValueError: field named x not found.
modifying ma.core.py so that
def __getitem__(self, indx):
...
if m is not nomask:
if not isinstance(indx, basestring):
dout._mask = ndarray.__getitem__(m,
indx).reshape(dout.shape)
...
gets me a little father. Any plans to make this style of record array
usage work with the new MaskedArray? I saw and experimented with
mrecords, but I am concerned about the performance overhead as I do
not require the granularity of fieldmask. Nevertheless, I will
continue with mrecords since it does what I want (and it is just
performance that I am worried about) and see how it works for me, but
I thought I would toss this other usage style out there because it
might be easy.
Thanks,
Alex
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] MaskedArray and the min,max,sum,prod Methods
Working with the new MaskedArray, I noticed the following differences with numpy.array behavior: masked_array([1, 2, 3], mask=True).min() 2147483647 array([]).min() Traceback (most recent call last): File stdin, line 1, in module ValueError: zero-size array to ufunc.reduce without identity masked_array([1, 2, 3], mask=True).max() -2147483648 array([]).max() Traceback (most recent call last): File stdin, line 1, in module ValueError: zero-size array to ufunc.reduce without identity masked_array([1, 2, 3], mask=True).prod() masked_array(data = --, mask = True, fill_value=1e+020) array([]).prod() 1.0 masked_array([1, 2, 3], mask=True).sum() masked_array(data = --, mask = True, fill_value=1e+020) numpy.array([]).sum() 0.0 Are these corner cases intentionally different? Thanks, Alex ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Thu, 3 Jan 2008, Charles R Harris apparently wrote: Isn't it trivially true that all elements of an empty array are close to any number? Sure, but might not one expect a ValueError due to shape mismatch? (Doesn't allclose usually use normal broadcasting rules?) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Hi, import numpy as np print np.__version__ a=np.int32(42) b=np.array([],dtype=np.int32) assert np.allclose(a,b) Is this expected behavior of numpy or is this a bug I should report? Bug, I think. I think this bug - which may be mine - follows from this line in allclose: return all(less_equal(absolute(x-y), atol + rtol * absolute(y))) and: In [39]: all([]) Out[39]: True Matthew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Thu, 3 Jan 2008, Charles R Harris apparently wrote: Isn't it trivially true that all elements of an empty array are close to any number? On Thu, 3 Jan 2008, Alan G Isaac apparently wrote: Sure, but might not one expect a ValueError due to shape mismatch? (Doesn't allclose usually use normal broadcasting rules?) Ooops, forgot that was a scalar, so it was normal: a*b array([], dtype=int32) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Just to ask - is there a reason why this: In [39]: all([]) Out[39]: True is the case? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
On Jan 3, 2008 2:37 PM, Matthew Brett [EMAIL PROTECTED] wrote: Just to ask - is there a reason why this: In [39]: all([]) Out[39]: True is the case? Because it's True. Anything is true about the elements of an empty set, because there aren't any. In this case, all asks if all elements in [] are true, i.e., does x member [] - x is true. Since x member [] is always false, the implication is always true. Recall that the statement x - y has the same truth value as the statement x' or xy. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
So, currently we have all and allclose giving the same answer: In [19]: a = array([]) In [20]: b = array([1]) In [21]: all(a == b) Out[21]: True In [22]: allclose(a, b) Out[22]: True Would we want the answers to be different? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Matthew Brett wrote: So, currently we have all and allclose giving the same answer: In [19]: a = array([]) In [20]: b = array([1]) In [21]: all(a == b) Out[21]: True In [22]: allclose(a, b) Out[22]: True Would we want the answers to be different? No. I wasn't thinking correctly, previously. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy code coverage
Stefan van der Walt wrote: Hi all, I read about Titus Brown's Figleaf code coverage tool [1] on the Planet SciPy aggregator [2]. The results of running figleaf on the numpy test-suite [3] covers Python code only. What the best way of discovering the C and C++ code coverage as well? I've never encountered any documents about checking C code coverage of Python extension modules. It is possible that the standard tools for C code coverage (e.g. gcov) would work fine with some finagling. If you try this, I would love to hear what you did. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
So, currently we have all and allclose giving the same answer: In [19]: a = array([]) In [20]: b = array([1]) In [21]: all(a == b) Out[21]: True In [22]: allclose(a, b) Out[22]: True Would we want the answers to be different? No. I wasn't thinking correctly, previously. It's unfortunate that all of us immediately think the given answer is wrong. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Error importing from numpy.matlib
Hi all, I can't figure out why this is happening ... I just recently recompiled numpy/scipy from svn just for the heck of it. Anyway, somewhere in my codebase (for a long time now) I'm doing: from numpy.matlib import * Now, when I try to use this code, or just type that in the interpreter, I get this message: AttributeError: 'module' object has no attribute 'pkgload' This doesn't happen when I do: import numpy.matlib as M Anyway, can anyone shed some light on this? Thanks, -steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unexpected behavior with allclose( scalar, empty array)
Matthew Brett wrote: So, currently we have all and allclose giving the same answer: In [19]: a = array([]) In [20]: b = array([1]) In [21]: all(a == b) Out[21]: True In [22]: allclose(a, b) Out[22]: True Would we want the answers to be different? No. I wasn't thinking correctly, previously. It's unfortunate that all of us immediately think the given answer is wrong. Maybe we need allclose_sameshape() (my ability to name stuff is terrible, but you get the idea). Regardless of the name issue, I have no idea how this is viewed against the no-namespace-bloat principle. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] weird indexing
Hi Okay, here's a weird one. In Fortran you can specify the upper/lower bounds of an array e.g. REAL A(3:7) What would be the best way to translate this to a Numpy array? I would like to do something like A=numpy.zeros(shape=(5,)) and have the expression A[3] actually return A[0]. Or something. Any thoughts? Mathew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
