Re: [Numpy-discussion] Array Protocol change for Python 2.6
Robert Kern wrote:
Francesc Altet wrote:
A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
Just out of curiosity:
In [1]: x = N.array([])
In [2]: x.__array_data__
Out[2]: ('0x01C23EE0', False)
Is there a reason why the __array_data__ tuple stores the address as a hex
string? I would guess that this representation of the address isn't the
most useful one for most applications.
Good point. I hit this before and forgot to send a message about this. I
agree
that a integer would be better. Although, now that I think about this, I
suppose that the issue should be the difference of representation of longs
in
32-bit and 64-bit platforms, isn't it?
Like how Win64 uses 32-bit longs and 64-bit pointers. And then there's
signedness. Please don't use Python ints to encode pointers. Holding arbitrary
pointers is the job of CObjects.
(Sorry, I'm late in reading this thread. I didn't know there were so many
numeric groups)
Python has functions to convert pointers to int/long and vice versa:
PyInt_FromVoidPtr()
and PyInt_AsVoidPtr(). ctypes uses them, ctypes also represents addresses as
ints/longs.
Thomas
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
A Divendres 16 Juny 2006 21:25, Thomas Heller va escriure: Robert Kern wrote: Like how Win64 uses 32-bit longs and 64-bit pointers. And then there's signedness. Please don't use Python ints to encode pointers. Holding arbitrary pointers is the job of CObjects. (Sorry, I'm late in reading this thread. I didn't know there were so many numeric groups) Python has functions to convert pointers to int/long and vice versa: PyInt_FromVoidPtr() and PyInt_AsVoidPtr(). ctypes uses them, ctypes also represents addresses as ints/longs. Very interesting. So, may I suggest to use this capability to represent addresses? I think this would simplify things (specially it will prevent to use ascii/pointer conversions, which are ugly to my mind). Cheers, -- 0,0 Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data - ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
Thomas Heller wrote:
Robert Kern wrote:
Francesc Altet wrote:
A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure:
Just out of curiosity:
In [1]: x = N.array([])
In [2]: x.__array_data__
Out[2]: ('0x01C23EE0', False)
Is there a reason why the __array_data__ tuple stores the address as a hex
string? I would guess that this representation of the address isn't the
most useful one for most applications.
Good point. I hit this before and forgot to send a message about this. I
agree
that a integer would be better. Although, now that I think about this, I
suppose that the issue should be the difference of representation of longs
in
32-bit and 64-bit platforms, isn't it?
Like how Win64 uses 32-bit longs and 64-bit pointers. And then there's
signedness. Please don't use Python ints to encode pointers. Holding
arbitrary
pointers is the job of CObjects.
(Sorry, I'm late in reading this thread. I didn't know there were so many
numeric groups)
Python has functions to convert pointers to int/long and vice versa:
PyInt_FromVoidPtr()
and PyInt_AsVoidPtr(). ctypes uses them, ctypes also represents addresses as
ints/longs.
The function calls are PyLong_FromVoidPtr() and PyLong_AsVoidPtr()
though, right? I'm happy representing pointers as Python integers
(Python long integers on curious platforms like Win64).
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
Albert Strasheim wrote:
Hello all
-Original Message-
From: [EMAIL PROTECTED] [mailto:numpy-
[EMAIL PROTECTED] On Behalf Of Travis Oliphant
Sent: 08 June 2006 22:27
To: numpy-discussion
Subject: [Numpy-discussion] Array Protocol change for Python 2.6
...
I would like to eliminate all the other array protocol attributes before
NumPy 1.0 (and re-label those such as __array_data__ that are useful in
other contexts --- like ctypes).
Just out of curiosity:
In [1]: x = N.array([])
In [2]: x.__array_data__
Out[2]: ('0x01C23EE0', False)
Is there a reason why the __array_data__ tuple stores the address as a hex
string? I would guess that this representation of the address isn't the most
useful one for most applications.
I suppose we could have stored it as a Python Long integer. But,
storing it as a string was probably inspired by SWIG.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
Tim Hochberg wrote: Sasha wrote: On 6/8/06, David M. Cooke [EMAIL PROTECTED] wrote: ... +0 for name change; I'm happy with it as an attribute. My rule of thumb for choosing between an attribute and a method is that attribute access should not create new objects. Interesting rule.In NumPy this is not quite the rule followed. Bascially attributes are used when getting or setting intrinsinc properties of the array. Attributes are used for properties that are important in defining what an array *is*. The flags attribute, for example, is an important intrinsinc property of the array but it returns an flags object when it is accessed. The flat attribute also returns a new object (it is arguable whether it should have been a method or an attribute but it is enough of an intrinsic property --- setting the flat attribute sets elements of the array -- that with historical precedence it was left as an attribute). By this meausure, the array interface should be an attribute. My problem with __array_struct__ returning either a tuple or a CObject is that array protocol sholuld really provide both. This is a convincing argument. Yes, the array protocol should provide both. Thus, we can't over-ride the usage of the same name unless that name produces an object through which both interfaces can be obtained. Is that Sasha's suggestion? A single attribute seems pretty appealing to me, I'm don't see much use for anything else. We still need __array_descr__, as the C struct doesn't provide all the info that this does. What do you have in mind? Is there any prospect of merging this data into the C struct? It would be cleaner if all of the information could be embedded into the C struct, but I can see how that might be a backward compatibility nightmare. I do think it should be merged into the C struct. The simplest thing to do is to have an additional PyObject * as part of the C struct which could be NULL (or unassigned). The backward compatibility is a concern but when thinking about what Python 2.6 should support we should not be too crippled by it. Perhaps we should just keep __array_struct__ and compress all the other array_interface methods into the __array_interface__ attribute which returns a dictionary from which the Python-side interface can be produced. Keep in mind there are two different (but related) issues at play here. 1) What goes in to NumPy 1.0 2) What we propose should go into Python 2.6 I think for #1 we should compress the Python-side array protocol into a single __array_interface__ attribute that returns a dictionary. We should also expand the C-struct to contain what _array_descr_ currently provides. -Travis ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
On 6/9/06, Travis Oliphant [EMAIL PROTECTED] wrote: ... In NumPy this is not quite the rule followed. Bascially attributes are used when getting or setting intrinsinc properties of the array. Attributes are used for properties that are important in defining what an array *is*. The flags attribute, for example, is an important intrinsinc property of the array but it returns an flags object when it is accessed. The flat attribute also returns a new object (it is arguable whether it should have been a method or an attribute but it is enough of an intrinsic property --- setting the flat attribute sets elements of the array -- that with historical precedence it was left as an attribute). By this meausure, the array interface should be an attribute. Array interface is not an intrinsic property of the array, but rather an alternative representation of the array itself. Flags are properly an attribute because they are settable. Something like x.flags()['WRITEABLE'] = False although technically possible, would be quite ugly. Similarly, shape attribute, although fails my rule of thumb by creating a new object, x.shape is x.shape False is justifiably an attribute because otherwise two methods: get_shape and set_shape would be required. I don't think flat should be an attribute, however. I could not find the reference, but I remember a discussion of why __iter__ should not be an attribute and IIRC the answer was because an iterator has a mutable state that is not reflected in the underlying object: x = arange(5) i = x.flat list(i) [0, 1, 2, 3, 4] list(i) [] list(x.flat) [0, 1, 2, 3, 4] My problem with __array_struct__ returning either a tuple or a CObject is that array protocol sholuld really provide both. This is a convincing argument. Yes, the array protocol should provide both. Thus, we can't over-ride the usage of the same name unless that name produces an object through which both interfaces can be obtained. Is that Sasha's suggestion? It was, but I quckly retracted it in favor of a mechanism to unpack the CObject. FWIW, I am also now -0 on the name change from __array_struct__ to __array_interface__ if what it provides is just a struct wrapped in a CObject. ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Array Protocol change for Python 2.6
On Fri, 09 Jun 2006 16:03:32 -0700 Andrew Straw [EMAIL PROTECTED] wrote: Tim Hochberg wrote: Which of the following should we require for an object to be supporting the array interface? Here a producer is something that supplies array_struct or array_interface (where the latter is the Python level version of the former as per recent messages). Consumers do something with the results. 1. Producers can supply either array_struct (if implemented in C) or array_interface (if implemented in Python). Consumers must accept both. 2. Producers must supply both array_struct and array_interface. Consumers may accept either. 3. Producers most supply both array_struct and array_interface. Consumers must accept both as well. I haven't been following as closely as I could, but is the following a possibility? 4. Producers can supply either array_struct or array_interface. Consumers may accept either. The intermediate is a small, standalone (does not depend on NumPy) extension module that does automatic translation if necessary by provides 2 functions: as_array_struct() (which returns a CObject) and as_array_interface() (which returns a tuple/dict/whatever). For something to go in the Python standard library this is certainly possible. Heck, if it's in the standard library we can have one attribute which is a special ArrayInterface object, which can be queried from both Python and C efficiently. For something like numpy (where we don't require a special object: the producer and consumers in Tim's terminology could be Numeric and numarray, for instance), we don't want a 3rd-party dependence. There's one case that I mentioned in another email: 5. Producers must supply array_interface, and may supply array_struct. Consumers can use either. Requiring array_struct means that Python-only modules can't play along, so I think it should be optional (of course, if you're concerned about speed, you would provide it). Or maybe we should revisit the no external dependencies. Perhaps one module would make everything easier, with helper functions and consistent handling of special cases. Packages wouldn't need it if they don't interact: you could conditionally import it when __array_interface__ is requested, and fail if you don't have it. It would just be required if you want to do sharing. -- ||\/| /--\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
