[Numpy-discussion] Re: Array Metadata
perry at stsci.edu
Wed Apr 6 15:05:47 EDT 2005
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
> 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
>> script. Since half it's purpose is for documentation, the Python
>> 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.
More information about the NumPy-Discussion