<br><br><div class="gmail_quote">On Sat, Jun 25, 2011 at 11:26 AM, Matthew Brett <span dir="ltr">&lt;<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi,<br>
<div class="im"><br>
On Sat, Jun 25, 2011 at 5:05 PM, Nathaniel Smith &lt;<a href="mailto:njs@pobox.com">njs@pobox.com</a>&gt; wrote:<br>
&gt; So obviously there&#39;s a lot of interest in this question, but I&#39;m<br>
&gt; losing track of all the different issues that&#39;ve being raised in the<br>
&gt; 150-post thread of doom. I think I&#39;ll find this easier if we start by<br>
&gt; putting aside the questions about implementation and such and focus<br>
&gt; for now on the *conceptual model* that we want. Maybe I&#39;m not the only<br>
&gt; one?<br>
&gt;<br>
&gt; So as far as I can tell, there are three different ways of thinking<br>
&gt; about masked/missing data that people have been using in the other<br>
&gt; thread:<br>
&gt;<br>
&gt; 1) Missingness is part of the data. Some data is missing, some isn&#39;t,<br>
&gt; this might change through computation on the data (just like some data<br>
&gt; might change from a 3 to a 6 when we apply some transformation, NA |<br>
&gt; True could be True, instead of NA), but we can&#39;t just &quot;decide&quot; that<br>
&gt; some data is no longer missing. It makes no sense to ask what value is<br>
&gt; &quot;really&quot; there underneath the missingness. And It&#39;s critical that we<br>
&gt; keep track of this through all operations, because otherwise we may<br>
&gt; silently give incorrect answers -- exactly like it&#39;s critical that we<br>
&gt; keep track of the difference between 3 and 6.<br>
<br>
</div>So far I see the difference between 1) and 2) being that you cannot<br>
unmask.  So, if you didn&#39;t even know you could unmask data, then it<br>
would not matter that 1) was being implemented by masks?<br>
<div class="im"><br></div></blockquote><div><br>Yes, bingo, you hit it right on the nose.  Essentially, 1) could be considered the &quot;hard mask&quot;, while 2) would be the &quot;soft mask&quot;.  Everything else is implementation details.<br>

 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
&gt; 2) All the data exists, at least in some sense, but we don&#39;t always<br>
&gt; want to look at all of it. We lay a mask over our data to view and<br>
&gt; manipulate only parts of it at a time. We might want to use different<br>
&gt; masks at different times, mutate the mask as we go, etc. The most<br>
&gt; important thing is to provide convenient ways to do complex<br>
&gt; manipulations -- preserve masks through indexing operations, overlay<br>
&gt; the mask from one array on top of another array, etc. When it comes to<br>
&gt; other sorts of operations then we&#39;d rather just silently skip the<br>
&gt; masked values -- we know there are values that are masked, that&#39;s the<br>
&gt; whole point, to work with the unmasked subset of the data, so if sum<br>
&gt; returned NA then that would just be a stupid hassle.<br>
<br>
</div>To clarify, you&#39;re proposing for:<br>
<br>
a = np.sum(np.array([np.NA, np.NA])<br>
<br>
1) -&gt; np.NA<br>
2) -&gt; 0.0<br>
<div class="im"><br>
?<br></div></blockquote><div><br>Actually, I have always considered this to be a bug.  Note that &quot;np.sum([])&quot; also returns 0.0.  I think the reason why it has been returning zero instead of NaN was because there wasn&#39;t a NaN-equivalent for integers.  This is where I think a np.NA could best serve NumPy by providing a dtype-agnostic way to represent missing or invalid data.<br>

<br>Ben Root<br></div></div>