[Numpy-discussion] Question for Travis

[Charles R Harris]

On Fri, May 30, 2008 at 1:19 AM, Travis E. Oliphant <oliphant at enthought.com>
wrote:

> Charles R Harris wrote:
> > Travis,
> >
> > What are the fundamental types for ndarrays? We have the c types,
> > 'bBhHiIlLqQfdg', together with the boolean and complex types. Then we
> > have types defined by length, int8, uint8, etc. The long types change
> > length going from 32 to 64 bit machines, so there can be a couple of
> > c-types corresponding to the same precision. So I am wondering which
> > types should be considered "fundamental" and what types are used to
> > identify pickled arrays and arrays stored with the new .nz formats.
> I don't know what you mean.
>
> Arrays can have dynamic PyArray_Descr objects.
>
> The "fundamental" ones would be the builtin ones which are the 21
> ctypes.   The int8, uint8, etc are also "fundamental" in the sense that
> they correspond to built-in types.
>

But not 1-1. The ufunc loops are all based on the c-types because, well,
they are in c. Now, if I ask for an int32 array on my machine, it has a
c-type of long, but if I store that array and recover it on a 64 bit
machine, the only available c-type of the right size is int, so in this case
the important part of the type is the int32 part and endianess. So I assume
that the size information is fundamental in that case and the association
with the c-type is made dynamically on a machine by machine basis. This
breaks down for float{80,96,128}, which is essentially non-portable because
the type is neither universal in format or size. So the second part of the
question is was what information is stored with the data to make it
recoverable on different architectures/compilers.

One of the things that brought this to mind was that promotions to larger
types in binary ufuncs will promote to long or int on my machine, depending
on the order of the arguments, which is a bit confusing. Likewise on 64 bit
machines the promotions go to both long and long long. So, in order to test
all the loops, I need the c-types, but the promotion rules depend on the
argument order, so they are not quite as simple and uniform as Robert
implies. In addition to that, there are 7 different promotion patterns in
both the unary and binary ufuncs, not counting the segfaults in remainder,
and these patterns are different on 32 and 64 bit machines. So my problem
from the testing point of view is to keep the tests as simple as possible
while at the same time making them portable. At the least, it looks like I
need to track the 32/64 bit information, but I'm also concerned about
possible compiler differences. Hmm, it looks like I will need tabulate the
c-types/precision pairings on each machine, then translate the expected
results on a function by function basis.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080530/1ec3f9f8/attachment.html>