[Numpy-discussion] alterNEP - was: missing data discussion round 2
Thu Jun 30 14:03:23 CDT 2011
On Thu, Jun 30, 2011 at 7:27 PM, Lluís <email@example.com> wrote:
> Matthew Brett writes:
>> I'm afraid, like you, I'm a little lost in the world of masking,
>> because I only need the NAs. I was trying to see if I could come up
>> with an API that picked up some of the syntactic convenience of NAs,
>> without conflating NAs with IGNOREs. I guess we need some feedback
>> from the 'NA & IGNORE Share the API' (NISA?) proponents to get an idea
>> of what we've missed. @Mark, @Chuck, guys - what have we lost here by
>> separating the APIs?
> As I tried to convey on my other mail, separating both will force you to
> * Make a copy of the array before passing it to another routine (because
> the routine will assign np.NA but you still want the original data)
You have an array 'arr'. The array does support NAs, but it doesn't
have a mask. You want to pass ``arr`` to another routine ``func``.
You expect ``func`` to set NAs into the data but you don't want
``func`` to modify ``arr`` and you don't want to copy ``arr`` either.
You are saying the following:
"with the fused API, I can make ``arr`` be a masked array, and pass it
into ``func``, and know that, when func sets elements of arr to NA, it
will only modify the mask and not the underlying data in ``arr``."
It does seem to me this is a very obscure case. First, ``func`` is
modifying the array but you want an unmodified array back. Second,
you'll have to do some view trick to recover the not-NA case to arr,
when it comes back.
It seems to me, that what ``func`` should do, if it wants you to be
able to unmask the NAs, is to make a masked array view of ``arr``, and
return that. And indeed the simplicity of the separated API
immediately makes that clear - in my view at least.
More information about the NumPy-Discussion