numpy-discussion

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[Robert K. <rob...@gm...>]

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.

-- 
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

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[Thomas H. <th...@py...>]

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

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[Francesc A. <fa...@ca...>]

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:=20
> 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=20
addresses? I think this would simplify things (specially it will prevent to=
=20
use ascii/pointer conversions, which are ugly to my mind).

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[Travis O. <oli...@ie...>]

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

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[Travis O. <oli...@ee...>]

Albert Strasheim wrote:

>Hello all
>
>  
>
>>-----Original Message-----
>>From: num...@li... [mailto:numpy-
>>dis...@li...] 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