[Numpy-discussion] NA/Missing Data Conference Call Summary

[Neal Becker]

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