[Numpy-discussion] __array_typestr__

Travis Oliphant oliphant at ee.byu.edu
Fri Apr 1 01:30:38 EST 2005

For the most part, it seems the array protocol is easy to agree on.  The 
one difficulty is typestr.

For what it's worth, here are my opinions on what has been said 
regarding the typestr.

* Endian-ness should be included in the typestr --- it is how the data 
is viewed and an intrinsic part of the type as much as int, or float.

* I like the fact that struct character codes are documented, but it is 
hard to remember.  The simpler division into basic types and byte-widths 
that the numarray record module uses is easier to remember. 

* I'm mixed on whether or not support for describing complex data types 
should be used or if their description as a record is good enough.  On 
the one hand we think of complex numbers as additional types, but on the 
other hand, in terms of machine layout they really are just two floats, 
so perhaps it is better to look at them that way in a protocol whose 
purpose is just describing how to interpret a block of memory.   
Especially since complex numbers could conceivably be built on top of 
any of the other types.   In addition, it is conceivable that a rational 
array might be supported by some array object in the future and that 
would most easily be handled by a record array where the names were now 
something like ("numer", "denom") .   The typestr argument should just 
help us specify what is in the memory chunk at each array element (how 
should it be described). 

* I'm wondering about including multiple types in the typestr.  On the 
one hand we could describe complicated structures by packing all the 
information into the  typestr.  On the other hand, it may be better if 
we just use 'V8' to describe an 8-byte memory buffer with  an additional 
attribute that contains both the names and the typestr:

__array_recinfo__ = (('real','f4'),('imag','f4'))

or  for a "rational type"

__array_recinfo__ = (('numer','i4'),('denom','i4'))

so that the detail of the typecode for a "record" type is handled by 
another special method using tuples.    On this level, we could add the 
possibility of specifying a shape for a small array inside (just like 
the record array of numarray does).


More information about the NumPy-Discussion mailing list