<br><br><div class="gmail_quote">On Wed, Mar 7, 2012 at 12:26 PM, Nathaniel Smith <span dir="ltr">&lt;<a href="mailto:njs@pobox.com">njs@pobox.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Mar 7, 2012 at 5:17 PM, Charles R Harris<br>
&lt;<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>&gt; wrote:<br>
&gt; On Wed, Mar 7, 2012 at 9:35 AM, Pierre Haessig &lt;<a href="mailto:pierre.haessig@crans.org">pierre.haessig@crans.org</a>&gt;<br>
</div><div class="im">&gt;&gt; Coming back to Travis proposition &quot;bit-pattern approaches to missing<br>
&gt;&gt; data (*at least* for float64 and int32) need to be implemented.&quot;, I<br>
&gt;&gt; wonder what is the amount of extra work to go from nafloat64 to<br>
&gt;&gt; nafloat32/16 ? Is there an hardware support NaN payloads with these<br>
&gt;&gt; smaller floats ? If not, or if it is too complicated, I feel it is<br>
&gt;&gt; acceptable to say &quot;it&#39;s too complicated&quot; and fall back to mask. One may<br>
&gt;&gt; have to choose between fancy types and fancy NAs...<br>
&gt;<br>
&gt; I&#39;m in agreement here, and that was a major consideration in making a<br>
&gt; &#39;masked&#39; implementation first.<br>
<br>
</div>When it comes to &quot;missing data&quot;, bitpatterns can do everything that<br>
masks can do, are no more complicated to implement, and have better<br>
performance characteristics.<br>
<div class="im"><br></div></blockquote><div><br>Maybe for float, for other things, no. And we have lots of otherthings. The performance is a strawman, and it *isn&#39;t* easier to implement.<br> <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; Also, different folks adopt different values<br>
&gt; for &#39;missing&#39; data, and distributing one or several masks along with the<br>
&gt; data is another common practice.<br>
<br>
</div>True, but not really relevant to the current debate, because you have<br>
to handle such issues as part of your general data import workflow<br>
anyway, and none of these is any more complicated no matter which<br>
implementations are available.<br>
<div class="im"><br>
&gt; One inconvenience I have run into with the current API is that is should be<br>
&gt; easier to clear the mask from an &quot;ignored&quot; value without taking a new view<br>
&gt; or assigning known data. So maybe two types of masks (different payloads),<br>
&gt; or an additional flag could be helpful. The process of assigning masks could<br>
&gt; also be made a bit easier than using fancy indexing.<br>
<br>
</div>So this, uh... this was actually the whole goal of the &quot;alterNEP&quot;<br>
design for masks -- making all this stuff easy for people (like you,<br>
apparently?) that want support for ignored values, separately from<br>
missing data, and want a nice clean API for it. Basically having a<br>
separate .mask attribute which was an ordinary, assignable array<br>
broadcastable to the attached array&#39;s shape. Nobody seemed interested<br>
in talking about it much then but maybe there&#39;s interest now?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>Come off it, Nathaniel, the problem is minor and fixable. The intent of the initial implementation was to discover such things. These things are less accessible with the current API *precisely* because of the feedback from R users. It didn&#39;t start that way.<br>
<br>We now have something to evolve into what we want. That is a heck of a lot more useful than endless discussion.<br><br>Chuck <br></div></div>