<div class="gmail_quote">On Wed, Nov 2, 2011 at 6:37 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;">

Hi again,<br>
<br>
Okay, here&#39;s my attempt at an *uncontroversial* email!<br>
<br>
Specifically, I think it&#39;ll be easier to talk about this NA stuff if<br>
we can establish some common ground, and easier for people to follow<br>
if the basic points of agreement are laid out in one place. So I&#39;m<br>
going to try and summarize just the things that we can agree about.<br>
<br>
Note that right now I&#39;m *only* talking about what kind of tools we<br>
want to give the user -- i.e., what kind of problems we are trying to<br>
solve. AFAICT we don&#39;t have as much consensus on implementation<br>
matters, and anyway it&#39;s hard to make implementation decisions without<br>
knowing what we&#39;re trying to accomplish.<br>
<br>
1) I think we have consensus that there are (at least) two different<br>
possible ways of thinking about this problem, with somewhat different<br>
constituencies. Let&#39;s call these two concepts &quot;MISSING data&quot; and<br>
&quot;IGNORED data&quot;.<br>
<br>
2) I also think we have at least a rough consensus on what these<br>
concepts mean, and what their supporters want from them:<br>
<br>
MISSING data:<br>
- Conceptually, MISSINGness acts like a property of a datum --<br>
assigning MISSING to a location is like assigning any other value to<br>
that location<br>
- Ufuncs and other operations must propagate these values by default,<br>
and there must be an option to cause them to be ignored<br>
- Must be competitive with NaNs in terms of speed and memory usage (or<br>
else people will just use NaNs)<br>
- Compatibility with R is valuable<br>
- To avoid user confusion, ideally it should *not* be possible to<br>
&#39;unmask&#39; a missing value, since this is inconsistent with the &quot;missing<br>
value&quot; metaphor (e.g., see Wes&#39;s comment about &quot;leaky abstractions&quot;)<br>
- Possible useful extension: having different classes of missing<br>
values (similar to Stata)<br>
- Target audience: data analysis with missing data, neuroimaging,<br>
econometrics, former R users, ...<br>
<br>
IGNORED data:<br>
- Conceptually, IGNOREDness acts like a property of the array --<br>
toggling a location to be IGNORED is kind of vaguely similar to<br>
changing an array&#39;s shape<br>
- Ufuncs and other operations must ignore these values by default, and<br>
there doesn&#39;t really need to be a way to propagate them, even as an<br>
option (though it probably wouldn&#39;t hurt either)<br>
- Some memory overhead is inevitable and acceptable<br>
- Compatibility with R neither possible nor valuable<br>
- Ability to toggle the IGNORED state of a location is critical, and<br>
should be as convenient as possible<br>
- Possible useful extension: having not just different types of<br>
ignored values, but richer ways to combine them -- e.g., the example<br>
of combining astronomical images with some kind of associated<br>
per-pixel quality scores, where one might want the &#39;mask&#39; to be not<br>
just a boolean IGNORED/not-IGNORED flag, but an integer (perhaps a<br>
multi-byte integer) or even a float, and to allow these &#39;masks&#39; to be<br>
combined in some more complex way than just logical_and.<br>
- Target audience: anyone who&#39;s already doing this kind of thing by<br>
hand using a second mask array + boolean indexing, former <a href="http://numpy.ma" target="_blank">numpy.ma</a><br>
users, matplotlib, ...<br>
<br>
3) And perhaps we can all agree that the biggest *un*resolved question<br>
is whether we want to:<br>
- emphasize the similarities between these two use cases and build a<br>
single interface that can handle both concepts, with some compromises<br>
- or, treat these at two mostly-separate features that can each become<br>
exactly what the respective constituency wants without compromise --<br>
but with some potential redundancy and extra code.<br>
Each approach has advantages and disadvantages.<br>
<br>
Does that seem like a fair summary? Anything more we can add? Most<br>
importantly, anything here that you disagree with? Did I summarize<br>
your needs well? Do you have a use case that you feel doesn&#39;t fit<br>
naturally into either category?<br>
<br>
[Also, I thought this might make the start of a good wiki page for<br>
people to reference during these discussions, but I don&#39;t seem to have<br>
edit rights. If other people agree, maybe someone could put it up, or<br>
give me access? My trac id is <a href="mailto:njs@pobox.com">njs@pobox.com</a>.]<br>
<br>
Thanks,<br>
-- Nathaniel<br></blockquote><div><br>I want to pare this down even more.  I think the above lists makes too many unneeded extrapolations.<br><br>MISSING data:<br>
- Conceptually, MISSINGness acts like a property of a datum --<br>
assigning MISSING to a location is like assigning any other value to<br>
that location<br>
- Ufuncs and other operations must propagate these values by default,<br>
and there must be an option to cause them to be ignored<br>- Assigning MISSING is destructive<br>- Must be competitive with NaNs in terms of speed and memory usage (or<br>
else people will just use NaNs)<br>
- Target audience: data analysis with missing data, neuroimaging,<br>


econometrics, former R users, ...<br><br><br>- Possible useful extension: having different classes of missing<br>
values (similar to Stata)<br>
<br><br>IGNORED data:<br>
- Conceptually, IGNOREDness acts like a property of the array --<br>
toggling a location to be IGNORED is kind of vaguely similar to<br>
changing an array&#39;s shape<br>
- Ufuncs and other operations must ignore these values by default, and<br>
there doesn&#39;t really need to be a way to propagate them, even as an<br>
option (though it probably wouldn&#39;t hurt either)<br>
- Assigning IGNORE is non-destructive<br>
- Must be competitive with <a href="http://np.ma">np.ma</a> for speed and memory (or else users would just use <a href="http://np.ma">np.ma</a>)<br>

- Target audience: anyone who&#39;s already doing this kind of thing by<br>

hand using a second mask array + boolean indexing, former <a href="http://numpy.ma/" target="_blank">numpy.ma</a><br>

users, matplotlib, ...<br><br><br>- Possible useful extension: having not just different types of<br>
ignored values, but richer ways to combine them -- e.g., the example<br>
of combining astronomical images with some kind of associated<br>
per-pixel quality scores, where one might want the &#39;mask&#39; to be not<br>
just a boolean IGNORED/not-IGNORED flag, but an integer (perhaps a<br>
multi-byte integer) or even a float, and to allow these &#39;masks&#39; to be<br>
combined in some more complex way than just logical_and.<br>
<br><br><br>Then, as a third-party module developer, I can tell you that having separate and independent ways to detect &quot;MISSING&quot;/&quot;IGNORED&quot; would likely make support more difficult and would greatly benefit from a common (or easily combinable) method of identification.<br>

<br>Ben Root<br><br>P.S. - I took out the phrase &quot;compatibility with R&quot; not as a slight against R, but because of the vagueness of the statement.  Does it mean raw binary data format compatibility? Some sort of ABI compatibility (does R or python have the ability to call and pass data to each other?). Rather, I find the declaration of R-users being the target audience *much* more important and allows for more flexibility in achieving that goal for both forms of data.<br>

</div></div>