<br><br><div class="gmail_quote">On Sat, May 19, 2012 at 9:21 AM, Mark Wiebe <span dir="ltr"><<a href="mailto:mwwiebe@gmail.com" target="_blank">mwwiebe@gmail.com</a>></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><div class="h5">On Sat, May 19, 2012 at 10:00 AM, David Cournapeau <span dir="ltr"><<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>></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><div>On Sat, May 19, 2012 at 3:17 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></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><div>On Fri, May 18, 2012 at 3:47 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
After reading all the discussion around masked arrays and getting input from as many people as possible, it is clear that there is still disagreement about what to do, but there have been some fruitful discussions that ensued.<br>




<br>
This isn't really new as there was significant disagreement about what to do when the masked array code was initially checked in to master.   So, in order to move forward, Mark and I are going to work together with whomever else is willing to help with an effort that is in the spirit of my third proposal but has a few adjustments.<br>




<br>
The idea will be fleshed out in more detail as it progresses, but the basic concept is to create an (experimental) ndmasked object in NumPy 1.7 and leave the actual ndarray object unchanged.   While the details need to be worked out here,  a goal is to have the C-API work with both ndmasked arrays and arrayobjects (possibly by defining a base-class C-level structure that both ndarrays inherit from).     This might also be a good way for Dag to experiment with his ideas as well but that is not an explicit goal.<br>




<br>
One way this could work, for example is to have PyArrayObject * be the base-class array (essentially the same C-structure we have now with a HASMASK flag). Then, the ndmasked object could inherit from PyArrayObject * as well but add more members to the C-structure.     I think this is the easiest thing to do and requires the least amount of code-change.      It is also possible to define an abstract base-class PyArrayObject * that both ndarray and ndmasked inherit from.     That way ndarray and ndmasked are siblings even though the ndarray would essentially *be* the PyArrayObject * --- just with a different type-hierarchy on the python side.<br>




<br>
This work will take some time and, therefore, I don't expect 1.7 to be released prior to SciPy Austin with an end of June target date.   The timing will largely depend on what time is available from people interested in resolving the situation.   Mark and I will have some availability for this work in June but not a great deal (about 2 man-weeks total between us).    If there are others who can step in and help, it will help accelerate the process.<br>




<br></blockquote></div></div><div><br>This will be a difficult thing for others to help with since the concept is vague, the design decisions seem to be in your and Mark's hands, and you say you don't have much time. It looks to me like 1.7 will keep slipping and I don't think that is a good thing. Why not go for option 2, which will get 1.7 out there and push the new masked array work in to 1.8? Breaking the flow of development and release has consequences, few of them good.<br>


</div></div></blockquote><div><br></div></div></div><div>Agreed. 1.6.0 was released one year ago already, let's focus on polishing what's in there *now*. I have not followed closely what the decision was for a LTS release, but if 1.7 is supposed to be it, that's another argument about changing anything there for 1.7.</div>

</div></blockquote><div><br></div></div></div><div>The motivation behind splitting the mask out into a separate ndmasked is primarily so that pre-existing code will not silently function on NA-masked arrays and produce incorrect results. This centres around using PyArray_DATA to get at the data after manually checking flags, instead of calling PyArray_FromAny. Maybe a reasonable solution is to tweak the behavior of PyArray_DATA? It could work as follows:</div>

<div><br></div><div>- If an ndarray has no mask, PyArray_DATA returns the data pointer as it does currently.</div><div>- If the ndarray has an NA-mask, PyArray_DATA sets an exception and returns NULL</div><div>- Create a new accessor, PyArray_DATAPTR or PyArray_RAWDATA, which returns the array data under all circumstances.</div>

<div><br></div><div>This way, code which currently uses the data pointer through PyArray_DATA will fail instead of silently working with the wrong interpretation of the data. What do people feel about this idea?</div><div>

<br></div></div></blockquote><div><br>Code working with the wrong interpretation of the data doesn't bother me much at this point in development. Long term it matters, but in the short term we can't expect code not explicitly written to work with masked arrays to do the right thing. I think we are looking at a period of several years before things settle out and get accepted. First, the implementation and its interface needs to get close to final form, and then the long slow process of adoption into things like matplotlib needs to take place. I'd quess three to five years for that process.<br>
<br>That said, my main concern is to move forward and not spend the next year waiting. I see splitting the masked code out as rather like the python types having pointers to sequence/numerical/etc methods, i.e., ndarray then looks something like an abstract class. I don't have a problem with that and it does avoid base object bloat. As to having PyArray_DATA fail for masked arrays and provide new functions for unrestricted access, I'd be tempted to have PyArray_DATA continue to behave as it does and let the new functions return the error for masked arrays. Making third party applications fail for masked arrays is going make masked arrays very unpopular. Most likely no one would use them and third party applications would feel no pressure to support them. Another possibility might be to have a compile flag that determines whether of not PyArray_Data returns an error for masked arrays, something like we do now for deprecating old macros. <br>
<br>Chuck<br></div></div>