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 integer if it is a rank-0 array, otherwise raise an error. Yes. I think this makes a lot of sense because a rank-0 array can be seen as a scalar (and hence, and index), but it is difficult to see a rank-1 (or, in general, rank-N) array as a scalar (even if only has 1 single element). In particular, this would avoid this inconsistency: a[np.array(1)] 1 a[np.array([1])] array([1]) a[np.array([[[1]]])] array([[[1]]]) but: np.array(1).__index__() 1 np.array([1]).__index__() 1 np.array([[[1]]]).__index__() 1 This could potentially be changed in NumPy 2.0.I'm +0 on the suggestion. My vote is +1 for deprecating ``array([scalar])`` as a scalar index for NumPy 2.0. -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 perhaps work better. So do you want me to try out an implementation and supply a patch? If so, where should I send the patch? Ian attachment: ijstokes.vcf___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 context. Note also that at least Python's struct module (mis-?)uses __index__() for casting inputs to integers. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 several other contexts, e.g. in casting to Python types and in boolean context. Note also that at least Python's struct module (mis-?)uses __index__() for casting inputs to integers. Uh, could you put some examples of this please? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 hash table miss). That's why I said that __getattr__ would perhaps work better. So do you want me to try out an implementation and supply a patch? If so, where should I send the patch? See here: http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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.
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 context.
Note also that at least Python's struct module (mis-?)uses
__index__() for casting inputs to integers.
Uh, could you put some examples of this please?
Sure:
if array([[1]]):
print OK
x = float(array([[1]]))
and for the second point, in Python/Modules/_struct.c:
95 static PyObject *
96 get_pylong(PyObject *v)
97 {
98 assert(v != NULL);
99 if (!PyLong_Check(v)) {
100 /* Not an integer; try to use __index__ to convert. */
101 if (PyIndex_Check(v)) {
import numpy as np, struct
struct.pack(i, np.array([1]))
'\x01\x00\x00\x00'
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 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 context.
Note also that at least Python's struct module (mis-?)uses
__index__() for casting inputs to integers.
Uh, could you put some examples of this please?
Sure:
if array([[1]]):
print OK
x = float(array([[1]]))
and for the second point, in Python/Modules/_struct.c:
95 static PyObject *
96 get_pylong(PyObject *v)
97 {
98 assert(v != NULL);
99 if (!PyLong_Check(v)) {
100 /* Not an integer; try to use __index__ to convert.
*/ 101 if (PyIndex_Check(v)) {
import numpy as np, struct
struct.pack(i, np.array([1]))
'\x01\x00\x00\x00'
I see. What I do not see if this behaviour is desirable (in fact, I
think it is not, but I may be wrong of course).
--
Francesc Alted
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 seems to confirm that the correct version is that in the first link, and also that NPY_OUT_ARRAY is wrong in the API docs. I haven't checked NPY_INOUT_FARRAY or NPY_OUT_FARRAY. Cheers, Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 the output I expected, a slice for column 0...
array([1, 4, 7])
BUT
s = SIO.StringIO(a, 2, 3
b, 5, 6
c, 8, 9)
g= genfromtxt(s, delimiter=', ', dtype=None)
g[:,0]
Produces the following error:
IndexError: invalid index
In the first case, genfromtxt returns me a 2d array (list of lists),
in the second it returns a list of tuples with an associated dtype
list of tuples.
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', 'i4'), ('f2', 'i4')])
thanks in advance for any assistance
Matt
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
4, 5, 6
7, 8, 9)
g= genfromtxt(s, delimiter=', ', dtype=None)
print g[:,0]
This produces the output I expected, a slice for column 0...
array([1, 4, 7])
BUT
s = SIO.StringIO(a, 2, 3
b, 5, 6
c, 8, 9)
g= genfromtxt(s, delimiter=', ', dtype=None)
g[:,0]
Produces the following error:
IndexError: invalid index
In the first case, genfromtxt returns me a 2d array (list of lists),
Well, not exactly.
When you use dtype=None, genfromtxt tries to guess the type of the columns.
Because in this case all your variables can be safely casted to integers,
genfromtxt considers that the dtype is uniform and it outputs a 2D array.
in the second it returns a list of tuples with an associated dtype
list of tuples.
Well, in this case, the first column is detected to be of type string, while
the other columns are of type integers (as the dtype shows you).
Therefore, genfromtxt considers that the dtype is structured and the output is
a 1D array (each line is a tuple of 3 elements, the first one '|S1', the 2nd
and 3rd ints
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', 'i4'), ('f2', 'i4')])
Select a column by its name:
yourarray['f0']
More info:
http://docs.scipy.org/doc/numpy/user/basics.rec.html
http://docs.scipy.org/doc/numpy/user/basics.io.genfromtxt.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] genfromtxt behaviour
snip
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', 'i4'), ('f2', 'i4')])
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 column.
Matt
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] genfromtxt behaviour
On Oct 29, 2010, at 2:59 PM, Matt Studley wrote:
snip
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', 'i4'), ('f2', 'i4')])
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 column.
For a structured array, yes, you get it.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 presented, the segfault occurs at the
call to PyArg_ParseTuple). I've been assuming that importing numpy into
the calling python code implicitly provides the numpy libraries that are
necessary for linking. I can only assume I'm missing something. Do i
need some additional includes etc in my compile flags?
I'm currently using the distutils.core module and not the distutils
module that comes with numpy if that makes a difference.
I'm actually pretty keen to document what I've learnt as a 5 minute
how-to for writing basic numpy extensions, if there is demand for it. It
doesn't seem to exist as a coherent whole at the moment.
Thanks,
Henry
#include Python.h
#include numpy/arrayobject.h
PyMODINIT_FUNC
initspam(void);
static PyObject *
spam_system(PyObject *self, PyObject *args);
void
worker_function(double *input, double *output, npy_intp size);
static PyMethodDef SpamMethods[] = {
{system, spam_system, METH_VARARGS,
Execute a shell command.},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
initspam(void)
{
(void) Py_InitModule(spam, SpamMethods);
}
static PyObject *
spam_system(PyObject *self, PyObject *args)
{
int n;
int ndims;
PyObject *inarg=NULL, *outarg=NULL;
PyObject *inarr=NULL, *outarr=NULL;
/* Both input and output need to be PyArray_Type type*/
if (!PyArg_ParseTuple(args, O!O!, PyArray_Type, inarg,
PyArray_Type, outarg));
return NULL;
inarr = PyArray_FROM_OTF(inarg, NPY_DOUBLE, NPY_IN_ARRAY);
if (inarr == NULL) goto fail;
outarr = PyArray_FROM_OTF(outarg, NPY_DOUBLE, NPY_OUT_ARRAY);
if (outarr == NULL) goto fail;
/* Check the shape of the two arrays is the same */
ndims = ((PyArrayObject *)outarr)-nd;
if (((PyArrayObject *)inarr)-nd != ndims)
goto fail;
/* ...still checking...*/
for (n=1; nndims; n++)
{
if (PyArray_DIM(inarr,n) != PyArray_DIM(outarr,n))
goto fail;
}
/* Now actually do something with the arrays */
worker_function((double *)PyArray_DATA(inarr),
(double *)PyArray_DATA(outarr),
PyArray_Size(inarr));
Py_DECREF(inarr);
Py_DECREF(outarr);
return Py_None;
fail:
Py_XDECREF(inarr);
Py_XDECREF(outarr);
return NULL;
}
void
worker_function(double *input, double *output, npy_intp size)
{
npy_intp n;
for (n=0;nsize;n++)
{
output[n] = input[n] + 10;
}
return;
}
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Hi Travis
Hi Travis, Could you look over the thread about dtype comparisonshttp://thread.gmane.org/gmane.comp.python.numeric.general/41074/focus=41082and offer an opinion? TIA, Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 perhaps work better. So do you want me to try out an implementation and supply a patch? If so, where should I send the patch? Ian 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 You might want to check these out (or pitch in with those efforts) before starting up your own variant. (Though if your idea has more modest goals, then it might be a good complement to these more extensive/intrusive solutions.) Zach ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 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 accessPyArray_Type (so, as presented, the segfault occurs at the
call to PyArg_ParseTuple). I've been assuming that importing numpy into
the calling python code implicitly provides the numpy libraries that are
necessary for linking. I can only assume I'm missing something. Do i
need some additional includes etc in my compile flags?
I'm currently using the distutils.core module and not the distutils
module that comes with numpy if that makes a difference.
I'm actually pretty keen to document what I've learnt as a 5 minute
how-to for writing basic numpy extensions, if there is demand for it. It
doesn't seem to exist as a coherent whole at the moment.
Thanks,
Henry
#includePython.h
#includenumpy/arrayobject.h
PyMODINIT_FUNC
initspam(void);
static PyObject *
spam_system(PyObject *self, PyObject *args);
void
worker_function(double *input, double *output, npy_intp size);
static PyMethodDef SpamMethods[] = {
{system, spam_system, METH_VARARGS,
Execute a shell command.},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
initspam(void)
{
(void) Py_InitModule(spam, SpamMethods);
}
static PyObject *
spam_system(PyObject *self, PyObject *args)
{
int n;
int ndims;
PyObject *inarg=NULL, *outarg=NULL;
PyObject *inarr=NULL, *outarr=NULL;
/* Both input and output need to be PyArray_Type type*/
if (!PyArg_ParseTuple(args, O!O!,PyArray_Type,inarg,
PyArray_Type,outarg));
return NULL;
inarr = PyArray_FROM_OTF(inarg, NPY_DOUBLE, NPY_IN_ARRAY);
if (inarr == NULL) goto fail;
outarr = PyArray_FROM_OTF(outarg, NPY_DOUBLE, NPY_OUT_ARRAY);
if (outarr == NULL) goto fail;
/* Check the shape of the two arrays is the same */
ndims = ((PyArrayObject *)outarr)-nd;
if (((PyArrayObject *)inarr)-nd != ndims)
goto fail;
/* ...still checking...*/
for (n=1; nndims; n++)
{
if (PyArray_DIM(inarr,n) != PyArray_DIM(outarr,n))
goto fail;
}
/* Now actually do something with the arrays */
worker_function((double *)PyArray_DATA(inarr),
(double *)PyArray_DATA(outarr),
PyArray_Size(inarr));
Py_DECREF(inarr);
Py_DECREF(outarr);
return Py_None;
fail:
Py_XDECREF(inarr);
Py_XDECREF(outarr);
return NULL;
}
void
worker_function(double *input, double *output, npy_intp size)
{
npy_intp n;
for (n=0;nsize;n++)
{
output[n] = input[n] + 10;
}
return;
}
___
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] 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 for a minimum example that builds and runs. Thanks, Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 recarray is probably what I want. I need to play with this and see how easy it is to convert ndarrays into recarrays. The main thing is that I'm looking for something *really* simple that would, truly, just allow the conversion of: myarray['myaxis'] to myarray.myaxis My suggestion is to define __getattr__ directly on the ndarray class. This is, TTBOMK, only called if an attribute is *not* found on the object. In this event, prior to throwing an AttributeError exception, the object could check to see if the specified attribute exists as a named axis/dimension of the multi-dimensional array, and if so, return this. Otherwise, carry on with the AttributeError exception. 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 __getattr__(self,attr) method to the class. If someone can point me in the right direction, I'll keep looking into this, otherwise I'm giving up and will just try and use recarray. Ian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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/wiki/NdarrayWithNamedAxes Having looked into it more, I think recarray is probably what I want. I need to play with this and see how easy it is to convert ndarrays into recarrays. your_rec=your_array.view(np.recarray) The main thing is that I'm looking for something *really* simple that would, truly, just allow the conversion of: myarray['myaxis'] to myarray.myaxis Attribute-style access is IMHO the only interest of recarrays over regular structured arrays. Note that it comes to a cost... My suggestion is to define __getattr__ directly on the ndarray class. This is, TTBOMK, only called if an attribute is *not* found on the object. In this event, prior to throwing an AttributeError exception, the object could check to see if the specified attribute exists as a named axis/dimension of the multi-dimensional array, and if so, return this. Otherwise, carry on with the AttributeError exception. 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 __getattr__(self,attr) method to the class. If someone can point me in the right direction, I'll keep looking into this, otherwise I'm giving up and will just try and use recarray. Indeed. Check how recarray does it, for example. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] C extension compiling question
On Fri, Oct 29, 2010 at 08:45, Henry Gomersall wh...@cam.ac.uk 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 have a complete example somewhere. As in, a set of files for a minimum example that builds and runs. http://github.com/numpy/numpy/tree/master/doc/newdtype_example/ -- 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] C extension compiling question
- Original Message From: Henry Gomersall wh...@cam.ac.uk To: numpy-discussion numpy-discussion@scipy.org 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 numpy docs and the python extension docs). The code is given below. --- If you're trying to use numpy and standard pythons types, you might want to look into ctypes which allows you to write C extensions that pass arrays in a much easier way. I was into writing bare C extensions from the ground up like you when someone put me onto ctypes. MUCH easier and cleaner and, as a result, easier to debug. I recommend it. -- Lou Pecora, my views are my own. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 __getattr__(self,attr) method to the class. If someone can point me in the right direction, I'll keep looking into this, otherwise I'm giving up and will just try and use recarray. http://docs.python.org/c-api/typeobj.html#tp_getattro The Python documentation doesn't seem to say very if method/attribute slots are consulted before falling back to tp_getattro. If tp_getattro is consulted first, then implementing it will lead to a performance hit. I'd probably be +0 on providing recarray-like functionality on ordinary ndarrays, if it can be done without (significant) performance issues. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[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.polynomial.Polynomial([1]).roots() Traceback (most recent call last): File pyshell#140, line 1, in module np.polynomial.Polynomial([1]).roots() File string, line 485, in roots File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 280, in mapdomain [x] = as_series([x], trim=False) File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 137, in as_series raise ValueError(Coefficient array is empty) ValueError: Coefficient array is empty Josef ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots()
On Fri, Oct 29, 2010 at 10:41 AM, josef.p...@gmail.com 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.Polynomial([1]) Polynomial([ 1.], [-1., 1.]) np.polynomial.Polynomial([1]).roots() Traceback (most recent call last): File pyshell#140, line 1, in module np.polynomial.Polynomial([1]).roots() File string, line 485, in roots File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 280, in mapdomain [x] = as_series([x], trim=False) File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 137, in as_series raise ValueError(Coefficient array is empty) ValueError: Coefficient array is empty This has been fixed in trunk to return an empty array: In [2]: import numpy.polynomial as poly In [3]: p = poly.Polynomial([1]) In [4]: p Out[4]: Polynomial([ 1.], [-1., 1.]) In [5]: p.roots() Out[5]: array([], dtype=float64) What version are you seeing this in? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots()
On Fri, Oct 29, 2010 at 12:50 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Oct 29, 2010 at 10:41 AM, josef.p...@gmail.com 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.Polynomial([1]) Polynomial([ 1.], [-1., 1.]) np.polynomial.Polynomial([1]).roots() Traceback (most recent call last): File pyshell#140, line 1, in module np.polynomial.Polynomial([1]).roots() File string, line 485, in roots File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 280, in mapdomain [x] = as_series([x], trim=False) File C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py, line 137, in as_series raise ValueError(Coefficient array is empty) ValueError: Coefficient array is empty This has been fixed in trunk to return an empty array: In [2]: import numpy.polynomial as poly In [3]: p = poly.Polynomial([1]) In [4]: p Out[4]: Polynomial([ 1.], [-1., 1.]) In [5]: p.roots() Out[5]: array([], dtype=float64) What version are you seeing this in? I'm old, numpy 1.4.0 empty array is good, it works with the rest so far. Thanks, 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] 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, 2010, at 9:20 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi Travis, Could you look over the thread about dtype comparisons and offer an opinion? TIA, 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] 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 might want to chip in:
x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))])
x.T['a'].shape
(4, 3, 2)
x.T.copy()['a'].shape
(3, 2, 4)
Fortran-order is special-cased. We might want to change this to work like
so:
x.T['a'].shape
(3, 2, 4)
which is more predictable.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 p...@iki.fi wrote:
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 might want to chip in:
x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))])
x.T['a'].shape
(4, 3, 2)
x.T.copy()['a'].shape
(3, 2, 4)
Fortran-order is special-cased. We might want to change this to work like
so:
x.T['a'].shape
(3, 2, 4)
which is more predictable.
--
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
