Christopher Barker wrote: > Dag Sverre Seljebotn wrote: >> Here's an HPC perspective...: > >> At least I feel that the transparency of NumPy is a huge part of its >> current success. Many more than me spend half their time in C/Fortran >> and half their time in Python. > > Absolutely -- and this point has been raised a couple times in the > discussion, so I hope it is not forgotten. > > > I tend to look at NumPy this way: Assuming you have some data in memory >> (possibly loaded by a C or Fortran library). (Almost) no matter how it >> is allocated, ordered, packed, aligned -- there's a way to find strides >> and dtypes to put a nice NumPy wrapper around it and use the memory from >> Python. > > and vice-versa -- Assuming you have some data in numpy arrays, there's a > way to process it with a C or Fortran library without copying the data. > > And this is where I am skeptical of the bit-pattern idea -- while one > can expect C and fortran and GPU, and ??? to understand NaNs for > floating point data, is there any support in compilers or hardware for > special bit patterns for NA values to integers? I've never seen in my > (very limited experience). > > Maybe having the mask option, too, will make that irrelevant, but I want > to be clear about that kind of use case. > > -Chris
Am I the only one that finds the idea of special values of things like int[1] to have special meanings to be really ugly? [1] which already have defined behavior over their entire domain of bit patterns _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
