[Numpy-discussion] Re: Array Metadata

[Perry Greenfield]

Coming in very late...

On Apr 1, 2005, at 4:46 AM, Francesc Altet wrote:

> I'm very much with the opinions of Scott. Just some remarks.
>
> A Divendres 01 Abril 2005 06:12, Scott Gilbert va escriure:

>>> I also think that rather than attach < or > to the start of the
>>> string it would be easier to have another protocol for endianness.
>>> Perhaps something like:
>>>
>>> __array_endian__  (optional Python integer with the value 1 in it).
>>> If it is not 1, then a byteswap must be necessary.
>>
>> A limitation of this approach is that it can't adequately represent
>> struct/record arrays where some fields are big endian and others are 
>> little
>> endian.
>
> Having a mix of different endianess data values in the same data
> record would be a bit ill-minded. In fact, numarray does not support
> this: a recarray should be all little or big endian. I think that '<'
> and '>' would be more than enough to represent this.
>
Nothing intrinsically prevents numarray from allowing this for records, 
but I'd agree that I have a hard time understanding when a given record 
array would have mixed endianess.

>>> So, what if we proposed for the Python core not something like
>>> Numeric3 (which would still exist in scipy.base and be everybody's
>>> favorite array :-) ), but a very minimal array object (scaled back
>>> even from Numeric) that followed the array protocol and had some
>>> C-API associated with it.
>>>
>>> This minimal array object would support 5 basic types ('bool',
>>> 'integer', 'float', 'complex', 'Object').   (Maybe a void type
>>> could be defined and a void "scalar" introduced (which would be
>>> the bytes object)).  These types correspond to scalars already
>>> available in Python and so the whole 0-dim array Python scalar
>>> arguments could be ignored.
>>
>> I really like this idea.  It could easily be implemented in C or 
>> Python
>> script.  Since half it's purpose is for documentation, the Python 
>> script
>> implementation might make more sense.
>
> Yeah, I fully agree with this also.
>
>
I'm not against it, but I wonder if it is the most important thing to 
do next. I can imagine that there are many other issues that deserve 
more attention than this. But I won't tell Travis what to do, 
obviously. Likewise about working on the current Python array module.

Perry

Perry