Re: [Numpy-discussion] Hi Travis

Yeah. This does look odd and should be fixed. -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Oct 29, 2010, at 6:10 PM, Pauli Virtanen wrote: > Hi Travis! > > Fri, 29 Oct 2010 17:40:20 -0400, Travis Oliphant wrote: >> Thanks for pointing out the

Re: [Numpy-discussion] Hi Travis

Hi Travis! Fri, 29 Oct 2010 17:40:20 -0400, Travis Oliphant wrote: > Thanks for pointing out the discussion. This is an oversight. The > dtypes should not compare equal if the subarrays don't match. > > If the patch looks OK, then we should accept it. Another issue from the thread where you mi

Re: [Numpy-discussion] Hi Travis

Thanks for pointing out the discussion. This is an oversight. The dtypes should not compare equal if the subarrays don't match. If the patch looks OK, then we should accept it. Travis -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Oct 29, 201

Re: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots()

On Fri, Oct 29, 2010 at 12:50 PM, Charles R Harris wrote: > > > On Fri, Oct 29, 2010 at 10:41 AM, wrote: >> >> For the lag polynomials I have cases where the order is zero, but >> roots raises a ValueError. >> >> Is this intended? >> Then, I need to catch it in my code. I haven't checked yet if m

Re: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots()

On Fri, Oct 29, 2010 at 10:41 AM, wrote: > For the lag polynomials I have cases where the order is zero, but > roots raises a ValueError. > > Is this intended? > Then, I need to catch it in my code. I haven't checked yet if my other > parts will go through with empty roots. > > >>> np.polynomial.

[Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots()

For the lag polynomials I have cases where the order is zero, but roots raises a ValueError. Is this intended? Then, I need to catch it in my code. I haven't checked yet if my other parts will go through with empty roots. >>> np.polynomial.Polynomial([1]) Polynomial([ 1.], [-1., 1.]) >>> np.poly

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

Fri, 29 Oct 2010 09:58:33 -0400, Ian Stokes-Rees wrote: [clip] > I've spent an hour looking at the numpy code (my first time), and I > don't see any obvious way to do this, since ndarray is (AFAICT) a pure-C > object with auto-generated wrappers, which seems to preclude (easily) > adding a "__getat

Re: [Numpy-discussion] C extension compiling question

- Original Message From: Henry Gomersall To: numpy-discussion Sent: Fri, October 29, 2010 9:11:41 AM Subject: [Numpy-discussion] C extension compiling question I'm trying to get a really simple toy example for a numpy extension working (you may notice its based on the example in the num

Re: [Numpy-discussion] C extension compiling question

On Fri, Oct 29, 2010 at 08:45, Henry Gomersall wrote: > On Fri, 2010-10-29 at 15:33 +0200, Jon Wright wrote: >> >> You need to call import_array() in initspam. See: >> http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html > > Thanks, that solves it. > > It would be really useful to

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

On Oct 29, 2010, at 3:58 PM, Ian Stokes-Rees wrote: > >> Note that there are various extant projects that I think attempt to >> provide similar functionality to what you're wanting (unless I badly >> misread your original email, in which case apologies): >> http://projects.scipy.org/numpy/wi

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

> Note that there are various extant projects that I think attempt to > provide similar functionality to what you're wanting (unless I badly > misread your original email, in which case apologies): > http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes Having looked into it more, I think

Re: [Numpy-discussion] C extension compiling question

On Fri, 2010-10-29 at 15:33 +0200, Jon Wright wrote: > > You need to call import_array() in initspam. See: > http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html Thanks, that solves it. It would be really useful to have a complete example somewhere. As in, a set of files

Re: [Numpy-discussion] C extension compiling question

Dear Henry, You need to call import_array() in initspam. See: http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html HTH, Jon On 29/10/2010 15:11, Henry Gomersall wrote: > I'm trying to get a really simple toy example for a numpy extension > working (you may notice its based on t

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

>>> But wouldn't the performance hit only come when I use it in this >>> way? >>> __getattr__ is only called if the named attribute is *not* found (I >>> guess it falls off the end of the case statement, or is the result >>> of >>> the attribute hash table "miss"). >> That's why I said that __g

[Numpy-discussion] Hi Travis

Hi Travis, Could you look over the thread about dtype comparisonsand offer an opinion? TIA, Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scip

[Numpy-discussion] C extension compiling question

I'm trying to get a really simple toy example for a numpy extension working (you may notice its based on the example in the numpy docs and the python extension docs). The code is given below. The problem I am having is running the module segfaults at any attempt to access &PyArray_Type (so, as pre

Re: [Numpy-discussion] genfromtxt behaviour

On Oct 29, 2010, at 2:59 PM, Matt Studley wrote: > > >>> How can I do my nice 2d slicing on the latter? >>> >>> array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], >>> dtype=[('f0', '|S1'), ('f1', ' >> Select a column by its name: >> yourarray['f0'] > > Super! > > So I would need to get the

[Numpy-discussion] genfromtxt behaviour

>> How can I do my nice 2d slicing on the latter? >> >> array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], >> dtype=[('f0', '|S1'), ('f1', 'Select a column by its name: >yourarray['f0'] Super! So I would need to get the dtype object... myData[ myData.dtype.names[0] ] in order to index by col

Re: [Numpy-discussion] genfromtxt behaviour

On Oct 29, 2010, at 2:35 PM, Matt Studley wrote: > Hi all > > first, please forgive me for my ignorance - I am taking my first > stumbling steps with numpy and scipy. No problem, it;s educational > I am having some difficulty with the behaviour of genfromtxt. > > s = SIO.StringIO("""1, 2, 3 >

[Numpy-discussion] genfromtxt behaviour

Hi all first, please forgive me for my ignorance - I am taking my first stumbling steps with numpy and scipy. I am having some difficulty with the behaviour of genfromtxt. s = SIO.StringIO("""1, 2, 3 4, 5, 6 7, 8, 9""") g= genfromtxt(s, delimiter=', ', dtype=None) print g[:,0] This produces th

[Numpy-discussion] Error in API docs?

There is an inconsistency in the documentation for NPY_INOUT_ARRAY. cf. http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#NPY_INOUT_ARRAY http://docs.scipy.org/doc/numpy/reference/c-api.array.html#NPY_INOUT_ARRAY The first link includes the flag NPY_UPDATEIFCOPY. Checking the code se

Re: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays?

A Friday 29 October 2010 12:59:04 Pauli Virtanen escrigué: > pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti: > > A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigué: > > > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > > > [clip] > > > > > > > My vote is +1 for deprecat

Re: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays?

pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti: > A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigué: > > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > > [clip] > > > > > My vote is +1 for deprecating ``array([scalar])`` as a scalar index > > > for NumPy 2.0. > > > >

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

Hi, Fri, 29 Oct 2010 05:59:07 -0400, Ian Stokes-Rees wrote: >>> But wouldn't the performance hit only come when I use it in this way? >>> __getattr__ is only called if the named attribute is *not* found (I >>> guess it falls off the end of the case statement, or is the result of >>> the attribute

Re: [Numpy-discussion] Inconsistency with __index __() for rank-1 arrays?

A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigué: > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > [clip] > > > My vote is +1 for deprecating ``array([scalar])`` as a scalar index > > for NumPy 2.0. > > I'd be -0 on this, since 1-element Numpy arrays function like scalars > in

Re: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays?

Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: [clip] > My vote is +1 for deprecating ``array([scalar])`` as a scalar index for > NumPy 2.0. I'd be -0 on this, since 1-element Numpy arrays function like scalars in several other contexts, e.g. in casting to Python types and in boolean con

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

>> But wouldn't the performance hit only come when I use it in this way? >> __getattr__ is only called if the named attribute is *not* found (I >> guess it falls off the end of the case statement, or is the result of >> the attribute hash table "miss"). > That's why I said that __getattr__ would p

Re: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays?

Hi Travis, thanks for answering, A Friday 29 October 2010 06:34:52 Travis Oliphant escrigué: > The __index__ method returns an integer from an array. > > The current behavior follows the idea of "return an integer if there > is 1-element in the array" > > Your suggestion is to only return an int