On Fri, May 30, 2008 at 1:19 AM, Travis E. Oliphant <oliphant@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