Hi, On Fri, Jul 1, 2011 at 3:09 PM, Mark Wiebe <[email protected]> wrote: > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett <[email protected]> > wrote: >> >> Hi, >> >> On Fri, Jul 1, 2011 at 2:36 AM, Keith Goodman <[email protected]> wrote: >> > On Thu, Jun 30, 2011 at 10:51 AM, Nathaniel Smith <[email protected]> wrote: >> >> On Thu, Jun 30, 2011 at 6:31 AM, Matthew Brett >> >> <[email protected]> wrote: >> >>> In the interest of making the discussion as concrete as possible, here >> >>> is my draft of an alternative proposal for NAs and masking, based on >> >>> Nathaniel's comments. Writing it, it seemed to me that Nathaniel is >> >>> right, that the ideas become much clearer when the NA idea and the >> >>> MASK idea are separate. Please do pitch in for things I may have >> >>> missed or misunderstood: >> >> [...] >> >> >> >> Thanks for writing this up! I stuck it up as a gist so we can edit it >> >> more easily: >> >> https://gist.github.com/1056379/ >> >> This is your initial version: >> >> >> >> https://gist.github.com/1056379/c809715f4e9765db72908c605468304ea1eb2191 >> >> And I made a few changes: >> >> >> >> https://gist.github.com/1056379/33ba20300e1b72156c8fb655bd1ceef03f8a6583 >> >> Specifically, I added a rationale section, changed np.MASKED to >> >> np.IGNORE (as per comments in this thread), and added a vowel to >> >> "propmsk". >> > >> > It might be helpful to make a small toy class in python so that people >> > can play around with NA and IGNORE from the alterNEP. >> >> Thanks for doing this. >> >> I don't know about you, but I don't know where to work on the >> discussion or draft implementation, because I am not sure where the >> disagreement is. Lluis has helpfully pointed out a specific case of >> interest. Pierre has fed back with some points of clarification. >> However, other than that, I'm not sure what we should be discussing. >> >> @Mark >> @Chuck >> @anyone >> >> Do you see problems with the alterNEP proposal? > > Yes, I really like my design as it stands now, and the alterNEP removes a > lot of the abstraction and interoperability that are in my opinion the best > parts. I've made more updates to the NEP based on continuing feedback, which > are part of the pull request I want reviews for.
Ah - I think what you are saying is - too late I've started writing it. > Mainly: Reduced interoperability Meaning? > more complex implementation (leading to > more bugs), OK - but the discussion did not seem to be about the complexity of the implementation, but about the API. > and an unclear theoretical model for the masked part of i What's unclear? Or even different? >> Do you agree that the alterNEP proposal is easier to understand? > > > No. Do you agree that there are several people on the list who do thing that the alterNEP proposal is easier to understand? >> If not, can you explain why? > > My answers to that are already scattered in the emails in various places, > and in the various rationales and justifications provided in the NEP. I can't see any reference to the alterNEP or the idea of the separate API in the NEP. Can you point me to it? >> What do you see as the important points of difference between the NEP >> and the alterNEP? > > The biggest thing is the NEP supports more use cases in a clean way by > composition of different simpler components. It defines one clear missing > data abstraction, and proposes two implementations that are interchangeable > and can interoperate. The alterNEP proposes two independent APIs, reducing > interoperability and so significantly increasing the amount of learning > required to work with both of them. This also precludes switching between > the two approaches without a lot of work. Lluis gave a particular somewhat obscure case where it is convenient that the NA and IGNORE are the same. Are there any others? It seems to me the API you propose is a classic example of implicit rather than explicit, and that it would be very easy, at this stage, to fix that. > The current pull request that's sitting there waiting for review does not > have an impact on which approach goes ahead, but the code I'm doing now > does. This is a fairly large project, and I don't have a great length of > time to do it in, so I'm not going to participate extensively in the > alterNEP discussion. If you want to help me, please review my code and > provide specific feedback on my NEP (the code review system in github is > great for this too, I've received some excellent feedback on the NEP that > way). If you want to change my mind about things, please address the > specific design decisions you think are problematic by specifically > responding to lines in the NEP, as part of code-reviewing my pull request in > github. OK - unless you tell me differently I'l take that as 'the discussion of the separate API for NA and IGNORE is over as far as I am concerned'. I would say, for future reference, that if there is a substantial and reasonable discussion of the API, that is not well resolved, then it does harm to go ahead and implement regardless. Specifically, it demoralizes those of us who put energy into trying to have a substantial reasoned discussion. I think that's bad for the list and bad for the community. See you, Matthew _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
