Re: [Numpy-discussion] ANN: numarray-1.4.1

[Todd M. <jm...@st...>]

Travis Oliphant wrote:

> Todd Miller wrote:
>
>> Francesc Altet wrote:
>>
>>> Hi Todd,
>>>
>>> I've just installed numarray 1.4.1 and pass my tests over it.
>>> Everything goes well, except some small detail:
>>>
>>> Python 2.4.2 (#2, Sep 29 2005, 00:23:59)
>>> [GCC 4.0.2 (Debian 4.0.1-9)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>  
>>>
>>>>>> import Numeric
>>>>>> import numarray
>>>>>> Numeric.__version__
>>>>>>       
>>>>>
>>>>>
>>> '24.0b2'
>>>  
>>>
>>>>>> numarray.__version__
>>>>>>       
>>>>>
>>>>>
>>> '1.4.1'
>>>  
>>>
>>>>>> na=numarray.array([ 51.], type=numarray.Float64)
>>>>>> Numeric.array(na, typecode='d')
>>>>>>       
>>>>>
>>>>>
>>> Traceback (most recent call last):
>>>  File "<stdin>", line 1, in ?
>>> TypeError: expected a writeable buffer object
>>>  
>>>
>
>> This looks like a coordinated change in both numarray and Numeric.   
>> (Travis?)  I updated to Numeric-24.0 and all was well.
>
>
>
>> It appears the __array_data__ protocol improved to know about 
>> readonly-ness.  In order to support the readonly behavior in 
>> numarray,  I think the change must be made in lockstep.  We could 
>> however back out support for readonly while Numeric-24.0 becomes more 
>> pervasive.
>
>
> Yes, basically the __array_data__ protocol was essentially pointless 
> before because it just returned a buffer object which
>
> 1) did nothing more than the object itself supporting the buffer 
> protocol and
> 2) could not handle strided (discontiguous) arrays.
>
> The new array protocol handles the situation much better and allows 
> discontiguous arrays to be shared.
>
> However, it does create some backward compatibility issues.  But, 
> because Numeric 24.0b2 was a *beta* release I don't see this as a real 
> problem.

Yeah, that sounds ok...  I was thinking the array interface was a 
release or two older.

>   Get the final release of Numeric, which will handle the array 
> protocol correctly (note it will also handle the old __array_data__ 
> format as well).
>
> Todd,  I was not sure how to change numarray so it would consume the 
> new protocol correctly. 

I think numarray's multiple factory functions in numarray, strings, and 
records all need to be beefed up to look for it.

> So, I'm not sure how numarray interprets the __array_data__ attribute.

I don't know if it does right now.   Just to be clear,  what Francesc 
was talking about is *supplying* the array buffer from numarray as 
apparently defined in the __get_array_data__ method.  If 24b was the 
first time the array interface ever worked it sounds ok to leave your 
changes in and force an upgrade to 24 if a user uses that feature.  
Francesc?

Todd