There is an issue with the NumPy 1.7 release that we all need to understand. Doesn't including the missing-data attributes in the NumPy structure in a released version of NumPy basically commit to including those attributes in NumPy 1.8? I'm not comfortable with that, is everyone else? One possibility is to move those attributes to a C-level sub-class of NumPy.
I have heard from a few people that they are not excited by the growth of the NumPy data-structure by the 3 pointers needed to hold the masked-array storage. This is especially true when there is talk to potentially add additional attributes to the NumPy array (for labels and other meta-information). If you are willing to let us know how you feel about this, please speak up. Mark Wiebe will be in Austin for about 3 months. He and I will be hashing some of this out in the first week or two. We will present any proposal and ask questions to this list before acting. We will be using some phone calls and face-to-face communications to increase the bandwidth and speed of the conversations (not to exclude anyone). If you would like to be part of the in-person discussions let me know -- or just make your views known here --- they will be taken seriously. The goal is consensus for any major change in NumPy. If we can't get consensus, then we vote on this list and use a super-majority. If we can't get a super-majority, then except in rare circumstances we can't move forward. Heavy users of NumPy get higher voting privileges. My perspective is that we don't have consensus on the current additions to the NumPy data-structure to have the current additional attributes on the NumPy data-structure be included for long-term release. Best, -Travis On Mar 25, 2012, at 6:27 PM, Charles R Harris wrote: > > > On Sun, Mar 25, 2012 at 3:14 PM, Ralf Gommers <ralf.gomm...@googlemail.com> > wrote: > > > On Sat, Mar 24, 2012 at 10:13 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: > Hi All, > > There several problems with numpy master that need to be fixed before a > release can be considered. > Datetime on windows with mingw. > Bus error on SPARC, ticket #2076. > NA and real/complex views of complex arrays. > Number 1 has been proved to be particularly difficult, any help or > suggestions for that would be much appreciated. The current work has been > going in pull request 214. > > This isn't to say that there aren't a ton of other things that need fixing or > that we can skip out on the current stack of pull requests, but I think it is > impossible to consider a release while those three problems are outstanding. > Why do you consider (2) a blocker? Not saying it's not important, but there > are eight other open tickets with segfaults. Some are more esoteric than > other, but I don't see why for example #1713 and #1808 are less important > than this one. > > #1522 provides a patch that fixes a segfault by the way, could use a review. > > > I wasn't aware of the other segfaults, I'd like to get them all fixed... The > list was meant to elicit additions. > > I don't know where the missed floating point errors come from, but they are > somewhat dependent on the compiler doing the right thing and hardware > support. I'd welcome any insight into why we get them on SPARC (underflow) > and Windows (overflow). The windows buildbot doesn't seem to be updating > correctly since it is still missing the combinations method that is now part > of the test module. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
