[Numpy-discussion] Array interface

[Magnus Lie Hetland]

Travis Oliphant <oliphant at ee.byu.edu>:
>
[snip]
> 
> Let me finish this example:
> 
> Suppose you have a complex short int array with
> 
> __array_descr__ = [('real','i2'),('imag','i2')]
> 
> you could describe this as
> 
> __array_typestr__ = 'V4'  

Sure -- I can see how using 'V' makes sense... You're just telling the
host program how many bytes you've got, and that's it. That makes
sense to me. What I wondered about was what happened when you use a
more specific (and conflicting) type for the typestr...

> or think of it as a 4 byte integer if you want to make sure that another 
> array package that may not support void pointers can still manipulate 
> the data, and so the creator of the complex short int array may decide that
> 
> __array_typestr__ = 'i4'

This is basically what I'm wondering about. It would make sense (to
me) to say that the data type was 'V4', because that's simply less
specific, in a way. But saying 'i4' is just as specific as the complex
example, above -- but it means something else! You're basically giving
the program permission to interpret a four-byte complex number as a
four-byte integer, aren't you? Sounds almost like a recipe for
disaster to me :}

On the other hand -- there is no complex integer type in the
interface, and using 'c4' probably would be completely wrong as well.

I would almost be tempted to say that if __array_descr__ is in use,
__array_typestr__ *has* to use the 'V' type. (Or, one could make some
more complicated rules, perhaps, in order to allow other types.)

As for not supporting the 'V' type -- would that really be considered
a conforming implementation? According to the spec, "Objects wishing
to support an N-dimensional array in application code should look for
these attributes and use the information provided appropriately". The
typestr is required, so...

Perhaps the spec should be explicit about the shoulds/musts/mays of
the specific typecodes? What must be supported, what may be supported
etc.? Or perhaps that doesn't make sense? It just seems almost too bad
that one package would have to know what another package supports in
order to formulate its own typestr... It sort of throws part of the
interoperability out the window.

> is the right thing to do for packages that ignore the __array_descr__  
> attribute.
> 
> -Travis

-- 
Magnus Lie Hetland                    Fall seven times, stand up eight
http://hetland.org                                  [Japanese proverb]