[Numpy-discussion] Missing data wrap-up and request for comments

Charles R Harris charlesr.harris at gmail.com
Thu May 10 01:21:49 EDT 2012


On Wed, May 9, 2012 at 11:05 PM, Benjamin Root <ben.root at ou.edu> wrote:

>
>
> On Wednesday, May 9, 2012, Nathaniel Smith wrote:
>
>>
>>
>> My only objection to this proposal is that committing to this approach
>> seems premature. The existing masked array objects act quite
>> differently from numpy.ma, so why do you believe that they're a good
>> foundation for numpy.ma, and why will users want to switch to their
>> semantics over numpy.ma's semantics? These aren't rhetorical
>> questions, it seems like they must have concrete answers, but I don't
>> know what they are.
>>
>
> Based on the design decisions made in the original NEP, a re-made numpy.mawould have to lose _some_ features particularly, the ability to share
> masks. Save for that and some very obscure behaviors that are undocumented,
> it is possible to remake numpy.ma as a compatibility layer.
>
> That being said, I think that there are some fundamental questions that
> has concerned. If I recall, there were unresolved questions about behaviors
> surrounding assignments to elements of a view.
>
> I see the project as broken down like this:
> 1.) internal architecture (largely abi issues)
> 2.) external architecture (hooks throughout numpy to utilize the new
> features where possible such as where= argument)
> 3.) getter/setter semantics
> 4.) mathematical semantics
>
> At this moment, I think we have pieces of 2 and they are fairly
> non-controversial. It is 1 that I see as being the immediate hold-up here.
> 3 & 4 are non-trivial, but because they are mostly about interfaces, I
> think we can be willing to accept some very basic, fundamental, barebones
> components here in order to lay the groundwork for a more complete API
> later.
>
> To talk of Travis's proposal, doing nothing is no-go. Not moving forward
> would dishearten the community. Making a ndmasked type is very intriguing.
> I see it as a set towards eventually deprecating ndarray? Also, how would
> it behave with no.asarray() and no.asanyarray()? My other concern is a
> possible violation of DRY. How difficult would it be to maintain two
> ndarrays in parallel?
>
> As for the flag approach, this still doesn't solve the problem of legacy
> code (or did I misunderstand?)
>

My understanding of the flag is to allow the code to stay in and get
reworked and experimented with while keeping it from contaminating
conventional use.

The whole point of putting the code in was to experiment and adjust. The
rather bizarre idea that it needs to be perfect from the get go is
disheartening, and is seldom how new things get developed. Sure, there is a
plan up front, but there needs to be feedback and change. And in fact, I
haven't seen much feedback about the actual code, I don't even know that
the people complaining have tried using it to see where it hurts. I'd like
that sort of feedback.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120509/0ec3881f/attachment.html>


More information about the NumPy-Discussion mailing list