On Wed, Jul 6, 2011 at 2:53 PM, Neal Becker <[email protected]> wrote:
> 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 > > Umm, no, I find it ugly also. On the other hand, it is an useful artifact left to us by the ancients and solves a lot of problems. So in the absence of anything more standardized... Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
