<br><br><div class="gmail_quote">On Wed, Jun 29, 2011 at 11:53 AM, Mark Wiebe <span dir="ltr">&lt;<a href="mailto:mwwiebe@gmail.com">mwwiebe@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;">
<div class="gmail_quote"><div class="im">On Tue, Jun 28, 2011 at 7:34 AM, Lluís <span dir="ltr">&lt;<a href="mailto:xscript@gmx.net" target="_blank">xscript@gmx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Mark Wiebe writes:<br>
&gt; The design that&#39;s forming is a combination of:<br>
<br>
&gt; * Solve the missing data problem <br>
&gt; * My ideas of what a good solution looks like:<br>
&gt;    * applies to all NumPy dtypes in a fully general way<br>
&gt;    * high-performance, low overhead where possible<br>
&gt;    * makes the C-level implementation of NumPy nicer to work with, not harder<br>
&gt;    * easy to use from Python for unskilled programmers<br>
&gt;    * easy to use more powerful functionality from Python for skilled programmers<br>
&gt;    * satisfies all or most of the needs of the many users of arrays with a &quot;missing data&quot; aspect to them<br>
<br>
</div>I would add here an efficient mechanism to reinterpret exising data with<br>
different missing information (no copies of the backing array).<br>
<br>
Although I&#39;m not sure whether this requires first-class citizenship or<br>
not.<br></blockquote><div><br></div></div><div>I&#39;m calling this idea &quot;masking semantics&quot; generally. </div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
&gt; * All the feedback I&#39;m getting from discussions on the list<br>
</div>[...]<br>
<div>&gt; I&#39;ve updated a section &quot;Parameterized Data Type With NA Signal Values&quot;<br>
&gt; in the NEP with an idea for now an NA bit pattern approach could<br>
&gt; coexist and work together with the mask-based approach. I think I&#39;ve<br>
&gt; solved some of the generality and implementation obstacles, it would<br>
&gt; be great to get some feedback on that.<br>
<br>
</div>Some (obvious) thoughts about it:<br>
<br>
* Trivial to store, as the missing property is encoded in the value<br>
  itself.<br>
* Third-party (non-Python) code needs some interface to interpret these<br>
  without having to know the implementation details (although the<br>
  interface is rather trivial).<br>
* Data marked as missing loses its original value.<br>
* Reinterpreting the same data (memory buffer) with different missing<br>
  information requires either memory copies or separate mask arrays (see<br>
  above)<br>
<br>
So, while it (data types with NA signal values) has its advantages on a<br>
simpler interaction with 3rd party code and during long-term storage,<br>
masks will still be needed.<br>
<br>
I think that deciding on the value of NA signal values boils down to<br>
this question: should 3rd party code be able to interpret missing data<br>
information stored in the separate mask array?<br></blockquote><div><br></div></div><div>I&#39;m tossing around some variations of ideas using the iterator to provide a buffered mask-based interface that works uniformly with both masked arrays and NA dtypes. This way 3rd party C code only needs to implement one missing data mechanism to fully support both of NumPy&#39;s missing data mechanisms.</div>

<div><br></div></div></blockquote><div><br>;) Also, it avoids a horrible mass of code.<br><br>Chuck <br></div></div>