<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On re-reading, I want to make a couple of things clear: <div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) This "wrap-up" discussion is *only* for what to do for NumPy 1.7 in such a way that we don't tie our hands in the future. I do not believe we can figure out what to do for masked arrays in one short week. What happens beyond NumPy 1.7 should be still discussed and explored. My urgency is entirely about moving forward from where we are in master right now in a direction that we can all accept. The tight timeline is so that we do *something* and move forward. </div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2) I missed another possible proposal for NumPy 1.7 which is in the write-up that Mark and Nathaniel made: remove the masked array additions entirely possibly moving them to another module like numpy-dtypes.</div><div><br></div><div>Again, these are only for NumPy 1.7. What happens in any future NumPy and beyond will depend on who comes to the table for both discussion and code-development. </div><div><br></div><div>Best regards,</div><div><br></div><div>-Travis</div><div><br></div><div><br></div><div><div><br><div><div>On May 9, 2012, at 11:46 AM, Travis Oliphant wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hey all, <div><br></div><div>Nathaniel and Mark have worked very hard on a joint document to try and explain the current status of the missing-data debate. I think they've done an amazing job at providing some context, articulating their views and suggesting ways forward in a mutually respectful manner. This is an exemplary collaboration and is at the core of why open source is valuable. </div><div><br></div><div>The document is available here: </div><div> <a href="https://github.com/numpy/numpy.scipy.org/blob/master/NA-overview.rst">https://github.com/numpy/numpy.scipy.org/blob/master/NA-overview.rst</a></div><div><br></div><div>After reading that document, it appears to me that there are some fundamentally different views on how things should move forward. I'm also reading the document incorporating my understanding of the history, of NumPy as well as all of the users I've met and interacted with which means I have my own perspective that is not necessarily incorporated into that document but informs my recommendations. I'm not sure we can reach full consensus on this. We are also well past time for moving forward with a resolution on this (perhaps we can all agree on that). </div><div><br></div><div>I would like one more discussion thread where the technical discussion can take place. I will make a plea that we keep this discussion as free from logical fallacies <a href="http://en.wikipedia.org/wiki/Logical_fallacy">http://en.wikipedia.org/wiki/Logical_fallacy</a> as we can. I can't guarantee that I personally will succeed at that, but I can tell you that I will try. That's all I'm asking of anyone else. I recognize that there are a lot of other issues at play here besides *just* the technical questions, but we are not going to resolve every community issue in this technical thread. </div><div><br></div><div>We need concrete proposals and so I will start with three. Please feel free to comment on these proposals or add your own during the discussion. I will stop paying attention to this thread next Wednesday (May 16th) (or earlier if the thread dies) and hope that by that time we can agree on a way forward. If we don't have agreement, then I will move forward with what I think is the right approach. I will either write the code myself or convince someone else to write it. </div><div><br></div><div>In all cases, we have agreement that bit-pattern dtypes should be added to NumPy. We should work on these (int32, float64, complex64, str, bool) to start. So, the three proposals are independent of this way forward. The proposals are all about the extra mask part: </div><div><br></div><div>My three proposals: </div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* do nothing and leave things as is </div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* add a global flag that turns off masked array support by default but otherwise leaves things unchanged (I'm still unclear how this would work exactly)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* move Mark's "masked ndarray objects" into a new fundamental type (ndmasked), leaving the actual ndarray type unchanged. The array_interface keeps the masked array notions and the ufuncs keep the ability to handle arrays like ndmasked. Ideally, <a href="http://numpy.ma/">numpy.ma</a> would be changed to use ndmasked objects as their core. </div><div><br></div><div>For the record, I'm currently in favor of the third proposal. Feel free to comment on these proposals (or provide your own). </div><div><br></div><div>Best regards,</div><div><br></div><div>-Travis</div><div><br></div></div></blockquote></div><br></div></div></body></html>