[Numpy-discussion] NumPy release manager post
Hi all, You probably remember that I said that after numpy 1.7.0 was out I wanted to step down as release manager for NumPy and focus more on SciPy. That was 4.5 months ago, and now that 1.7.0 keeps being postponed I'm actually planning to not wait for it. I have found that it's not possible for me to handle overlapping NumPy and SciPy release schedules well, therefore even if the NA stuff is sorted out soon I don't think I could do a 1.7.0 release within the next 6-8 weeks. A possible 1.6.3 release I could still do without much trouble though. Travis has already volunteered to manage the next release - thanks for that Travis. If anyone else would like to pitch in, I'm sure that's very welcome too. It doesn't require that you already know everything there is to know about NumPy, just a willingness to dig in. Feel free to ask me either on- or off-list for more details. Cheers, Ralf P.S. I'll certainly not completely stop working on numpy (docs, testing, distutils, ...) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy release process, adding a compatibility test step.
Hi, may I suggest an addition to the release process... 'Tests against popular libraries that rely on numpy at the RC stage. Test at least these libraries pass their numpy related tests: matplotlib, scipy, pygame, (insert others here?). The release manage should ask the mailing list for people to test the RC against these libraries to make sure they work ok.' - This will catch problems like the ABI one with the recent release. - It is an explicit request for testing, with concrete tasks that people can do. Rather than a more abstract request for testing. - not much extra work for the release manager. testing work can be distributed to anyone who can try an app, or library with the binaries supplied in the RC stage of a release. - binary installer users can test as well, not just people who build from source. - tests libraries the numpy developers may not be using all the time themselves. On another project, adding this simple step helped prevent a number of bugs which affected other programs and libraries using the project. Before this was added we had a couple of releases which broke a few popular libraries/apps with very simple regressions or bugs. cu, ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release process, adding a compatibility test step.
On Sat, Feb 6, 2010 at 6:44 PM, René Dudfield ren...@gmail.com wrote: Hi, may I suggest an addition to the release process... 'Tests against popular libraries that rely on numpy at the RC stage. Test at least these libraries pass their numpy related tests: matplotlib, scipy, pygame, (insert others here?). The release manage should ask the mailing list for people to test the RC against these libraries to make sure they work ok.' - This will catch problems like the ABI one with the recent release. - It is an explicit request for testing, with concrete tasks that people can do. Rather than a more abstract request for testing. - not much extra work for the release manager. testing work can be distributed to anyone who can try an app, or library with the binaries supplied in the RC stage of a release. - binary installer users can test as well, not just people who build from source. - tests libraries the numpy developers may not be using all the time themselves. On another project, adding this simple step helped prevent a number of bugs which affected other programs and libraries using the project. Before this was added we had a couple of releases which broke a few popular libraries/apps with very simple regressions or bugs. Thanks for the suggestion, I agree this will be useful. And a lot easier to do than automated testing against other libraries, which will hopefully happen at some point in the future. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: 2008/4/25 Alan G Isaac : So, if X is 2 by 2, then X[0] will be a row vector. But if X is 1 by 2, then X[0] will be a scalar? Ouch! Bye bye generic code. On Fri, 25 Apr 2008, Stefan van der Walt apparently wrote: Yup. That's the current state of things. I do not understand. The released state of things is that for matrix ``x`` we have that ``x[0]`` is a **matrix**. I'm not working with SVN NumPy, but my understanding was that as of revision r5072 ``x[0]`` always returns a 1d array. The core requirement was that ``x[0][0]`` produce the first element of the matrix. I do not have time to look at the revision right now, but if a matrix ``x`` we have that ``x[0]`` can return a scalar, that is very undesirable. In current SVN: In [3]: x = np.matrix(np.arange(9).reshape((3,3))) In [5]: x Out[5]: matrix([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) In [6]: x[0] Out[6]: matrix([[0, 1, 2]]) In [7]: x[0,:] Out[7]: matrix([[0, 1, 2]]) In [8]: x[0][0] Out[8]: 0 In [9]: x[0,:][0] Out[9]: 0 In [10]: x[:,0] Out[10]: matrix([[0], [3], [6]]) In [11]: x[:,0][0] Out[11]: 0 In [12]: x[:2,:2][0] Out[12]: matrix([[0, 1]]) Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
I think the use of the term 'vector' in this thread is becoming a bit confusing. An M by N matrix is a vector. (I.e., it is an element of a vector space.) Many people use the terms row vector and column vector to refer to special matrices. What is special is *not* that they are vectors (since all matrices are) but that they are a single row or a single column. Perhaps better terminology would have been row matrix and column matrix. Using this terminology, we clearly expect a row matrix and a column matrix to have transposes. The question is, can their elements be indexed by scalars. The answer in all the proposals, I believe, is yes. I believe we are finding that this answer has some problems. x is a 2 by 2 matrix x[0] is a 1 by 2 matrix x[0][0] is x[0,0] GOOD!! y = x[0] - y is a 1 by 2 matrix y[0][0] is a TypeError BAD!! So I am becoming more and more persuaded that for a matrix ``x``: x[0] should be a 1d array (always!) x[0,:] should be a matrix The rule: use non-scalar indexing to extract submatrices fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote: In current SVN: In [6]: x[0] Out[6]: matrix([[0, 1, 2]]) I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. The agreement was: a) That x[0][0] should be equal to x[0,0] and b) That x[0,:] should be equal to x[0] (as for ndarrays) This breaks as little functionality as possible, at the cost of one (instead of two) API changes. We should now discuss the proposals on the table, choose a good one, and implement all the API changes necessary for 1.2 or 2. It's a pity we have to change the API again, but the current situation is not tenable. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On 25/04/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/4/25 Alan G Isaac [EMAIL PROTECTED]: I must have misunderstood: I thought the agreement was to provisionally return a 1d array for x[0], while we hashed through the other proposals. The agreement was: a) That x[0][0] should be equal to x[0,0] and b) That x[0,:] should be equal to x[0] (as for ndarrays) This breaks as little functionality as possible, at the cost of one (instead of two) API changes. Hold on. There has definitely been some confusion here. This is not what I thought I was suggesting, or what Alan thought he was suggesting. I do not think special-casing matrices for which one dimension happens to be one is a good idea at all, even temporarily. This is the kind of thing that drives users crazy. My suggested stopgap fix was to make x[0] return a 1D *array*; I feel that this will result in less special-casing. In fact I wasn't aware that anyone had proposed the fix you implemented. Can we change the stopgap solution? We should now discuss the proposals on the table, choose a good one, and implement all the API changes necessary for 1.2 or 2. It's a pity we have to change the API again, but the current situation is not tenable. Yes, well, it really looks unlikely we will be able to agree on what the correct solution is before 1.1, so I would like to have something non-broken for that release. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Fri, Apr 25, 2008 at 10:04 AM, Alan G Isaac [EMAIL PROTECTED] wrote: I think the use of the term 'vector' in this thread is becoming a bit confusing. An M by N matrix is a vector. (I.e., it is an element of a vector space.) Sure, but the important thing is the multiplication. If it wasn't we could just flatten them all and be done with this discussion. Super bonus, no need for the '*' operator. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Anne Archibald wrote: Yes, well, it really looks unlikely we will be able to agree on what the correct solution is before 1.1, so I would like to have something non-broken for that release. +1 on that! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
I was hoping to get NumPy 1.1 tagged today, but it seems very unlikely at this point. Unfortunately, I haven't followed the matrix discussion as closely as I would like, so I can't tell if there is anything so uncontroversial that it would make sense to change for the 1.1.0 release. If there is something that can be unanimously agreed on within the next 24 hours or so, I would be happy to have it included in 1.1. If not, I would rather see us move on to working on 1.2 and releasing 1.1 ASAP. If there is unanimous agreement on a minor fix, we will need document the changes on the release notes. So once an agreement is reached, could someone either send me some text to insert into the release notes or update the document themselves: http://projects.scipy.org/scipy/numpy/milestone/1.1.0 This also might be a good opportunity to start a new thread with a subject line like 1.2 matrices. The discussion about matrices in this thread makes it difficult for me to quickly see what still needs to done before the 1.1 release. And there may also be some members of the community who would be very interested in the matrices discussion, but aren't reading this thread. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Stéfan van der Walt [EMAIL PROTECTED]: I'm starting to see Chris Barker's point; allowing x[0] is causing more problems than it is worth. On the other hand, how would you index into a vector (as in http://en.wikipedia.org/wiki/Vector_(spatial)) without it? To answer my own question: you wouldn't. Vectors won't exist, everything will be 2D, always. I could go with that. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/24 Jarrod Millman [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote: Assuming we want the next version to : ignore values outside of range and accept and return the bin edges instead of the left edges, here could be the new signature for 1.1: h, edges = histogram(a, bins=10, normed=False, range=None, normed=False, new=False) If new=False, return the histogram and the left edges, with a warning that in the next version, the edges will be returned. If new=True, return the histogram and the edges. If range is given explicitly , raise a warning saying that in the next version, the outliers will be ignored. To ignore outliers, use new=True. If bins is a sequence, raise an error saying that bins should be an integer. To use explicit edges, use new=True. In 1.2, set new=True as the default, and in 2.3, remove new altogether. +1 That sounds fine to me assuming 2.3 is 1.3. Indeed. Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. David -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 David Huard [EMAIL PROTECTED]: 2008/4/24 Jarrod Millman [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 1:22 PM, David Huard wrote: Assuming we want the next version to : ignore values outside of range and accept and return the bin edges instead of the left edges, here could be the new signature for 1.1: h, edges = histogram(a, bins=10, normed=False, range=None, normed=False, new=False) If new=False, return the histogram and the left edges, with a warning that in the next version, the edges will be returned. If new=True, return the histogram and the edges. If range is given explicitly , raise a warning saying that in the next version, the outliers will be ignored. To ignore outliers, use new=True. If bins is a sequence, raise an error saying that bins should be an integer. To use explicit edges, use new=True. In 1.2, set new=True as the default, and in 2.3, remove new altogether. +1 That sounds fine to me assuming 2.3 is 1.3. Indeed. Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. Well, it's not... there is still an issue... give me a couple of minutes to fix it. David -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Thanks Chuck, I didn't know there were other tests for histogram outside of test_function_base. The error is now raised only if bins are passed explicitly and normed=True. David 2008/4/25 Charles R Harris [EMAIL PROTECTED]: On Fri, Apr 25, 2008 at 12:55 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 12:55 PM, David Huard [EMAIL PROTECTED] wrote: Done in r5085. I added a bunch of tests, but I'd appreciate if someone could double check before the release. This is not the time to introduce new bugs. Hopefully this is the end of the histogram saga. This one? ERROR: Ticket #632 -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/numpy/core/tests/test_regression.py, line 812, in check_hist_bins_as_list hist,edges = np.histogram([1,2,3,4],[1,2]) File /usr/lib/python2.5/site-packages/numpy/lib/function_base.py, line 184, in histogram raise ValueError, 'Use new=True to pass bin edges explicitly.' ValueError: Use new=True to pass bin edges explicitly. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Some, including me, stated that the matrix class suffer some deficiencies, so, after playing a bit with matrices, we always go back to the good old ndarray class. There were some arguments on this list what/if should be dome to correct it. I welcome any attempt to build a code that demonstrates an alternative. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם St?fan van der Walt נשלח: ה 24-אפריל-08 13:13 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] numpy release 2008/4/24 Nadav Horesh [EMAIL PROTECTED]: +1 +1 to what? I'm glad that Tim chimed in -- his opinion is always valued -- but I didn't see any concrete suggestions on how to improve the situation. I'll gladly wait for his code, though :) Regards St?fan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Wed, 23 Apr 2008 16:20:41 -0400, David Huard wrote: 2008/4/23, Stéfan van der Walt [EMAIL PROTECTED]: Of those tickets, the following are serious: http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is available?, David Huard) Fixing of histogram. I haven't found a way to fix histogram reliably without breaking the current behavior. There is a patch attached to the ticket, if the decision is to break histogram. Summary of the facts (again...): a) histogram's docstring does not match its behavior wrt discarding data b) given variable-width bins, histogram(..., normed=True) the results are wrong c) it might make more sense to handle discarding data in some other way than what histogram does now I think there are now a couple of choices what to do with this: A) Change the semantics of histogram function. Old code using histogram will just simply break, maybe in mysterious ways. B) Rename the bins parameter to bin_edges or something else, so that any old code using histogram immediately raises an exception that is easily understood. C) Create a new parameter with more sensible behavior and a name different from bins, and deprecate (at least giving sequences to) the bins parameter: put up a DeprecationWarning if the user does this, but still produce the same results as the old histogram. This way the user can forward-port her code at leisure. D) Or, retain the old behavior (values below lowest bin ignored) and just fix the docstring and the normed=True bug? (I have a patch doing this.) So which one (or something else) do we choose for 1.1.0? -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
I think a long term strategy needs to be adopted for histogram. Right now there is a great confusion in what the bins keyword does. Right now it is defined as the lower edge of each bin, meaning that the last bin is open ended and [inf,bin0 does not exist. While this may not be the right thing to fix in 1.1.0, I would really like to see it fixed somewhere down the line. On Apr 24, 2008, at 10:28 AM, Pauli Virtanen wrote: Wed, 23 Apr 2008 16:20:41 -0400, David Huard wrote: I haven't found a way to fix histogram reliably without breaking the current behavior. There is a patch attached to the ticket, if the decision is to break histogram. Summary of the facts (again...): a) histogram's docstring does not match its behavior wrt discarding data This is an easy fix and should definitively go into 1.1.0 :) b) given variable-width bins, histogram(..., normed=True) the results are wrong Also a quick fix that should be part of 1.1.0 c) it might make more sense to handle discarding data in some other way than what histogram does now I would like to see this, but it does not have to happen in 1.1.0 :) I think there are now a couple of choices what to do with this: A) Change the semantics of histogram function. Old code using histogram will just simply break, maybe in mysterious ways Not really a satisfactory approach. I really don't mind, even though it would break some code of mine. I would rather see a better function and have to do some code changes, than the current confusion. Other people will likely disagree. B) Rename the bins parameter to bin_edges or something else, so that any old code using histogram immediately raises an exception that is easily understood. Given this approach bin_edges would contain one more value than bins given that the right edge of the last bin has to be defined. C) Create a new parameter with more sensible behavior and a name different from bins, and deprecate (at least giving sequences to) the bins parameter: put up a DeprecationWarning if the user does this, but still produce the same results as the old histogram. This way the user can forward-port her code at leisure. I think this is probably the best approach to accommodate everyone. So which one (or something else) do we choose for 1.1.0? -- Pauli Virtanen Cheers Tommy ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
The problem I see with C is that it will break compatibility with the other histogram functions, which also use bins. So here is suggestion E: The most common use case ( I think) is the following: h, b = histogram(r, number_of_bins, normed=True/False) for which the function behaves correctly. Assuming we want the next version to : ignore values outside of range and accept and return the bin edges instead of the left edges, here could be the new signature for 1.1: h, edges = histogram(a, bins=10, normed=False, range=None, normed=False, new=False) If new=False, return the histogram and the left edges, with a warning that in the next version, the edges will be returned. If new=True, return the histogram and the edges. If range is given explicitly , raise a warning saying that in the next version, the outliers will be ignored. To ignore outliers, use new=True. If bins is a sequence, raise an error saying that bins should be an integer. To use explicit edges, use new=True. In 1.2, set new=True as the default, and in 2.3, remove new altogether. David 2008/4/24 Travis E. Oliphant [EMAIL PROTECTED]: Pauli Virtanen wrote: C) Create a new parameter with more sensible behavior and a name different from bins, and deprecate (at least giving sequences to) the bins parameter: put up a DeprecationWarning if the user does this, but still produce the same results as the old histogram. This way the user can forward-port her code at leisure. D) Or, retain the old behavior (values below lowest bin ignored) and just fix the docstring and the normed=True bug? (I have a patch doing this.) So which one (or something else) do we choose for 1.1.0? I like either C or D, but prefer C if it can be done before 1.1.0. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Wed, 23 Apr 2008, Timothy Hochberg apparently wrote: I think the way to go is to probably add some meta information I have added this as Proposal 4 at URL:http://www.scipy.org/MatrixIndexing Forgive anything said the misrepresents your intent. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/25 Alan G Isaac [EMAIL PROTECTED]: So, if X is 2 by 2, then X[0] will be a row vector. But if X is 1 by 2, then X[0] will be a scalar? Ouch! Bye bye generic code. Yup. That's the current state of things. Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Thu, Apr 24, 2008 at 11:16 AM, Timothy Hochberg [EMAIL PROTECTED] wrote: [CHOP] The proposals thus far don't address two of the major issues I have with the matrix class: The thing that seems missing to me is support for LAPACK's banded and packed (triangular) storage formats. I don't have an urgent need for it, but it seems like a serious front end for doing linear algebra should at least provide a convenient way to access all of what LAPACK offers. Perhaps these other formats could/should be supported by different classes, though, the way it is done for sparse matrices. But the fact that more matrix types could exist some day is all the more reason to make sure the interface makes sense for more than just strided memory. My hunch is if the API is workable for both ndarray matrices and sparse matrices, then it should be ok for these other formats too. --bb ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Fri, Apr 25, 2008 at 10:23 AM, Christopher Barker [EMAIL PROTECTED] wrote: Alan G Isaac wrote: On Thu, 24 Apr 2008, Christopher Barker apparently wrote: I suppose a Vector can be either a (n,1) or a (1,n) matrix that allows single indexing. This bothers me. So, if X is 2 by 2, then X[0] will be a row vector. But if X is 1 by 2, then X[0] will be a scalar? Ouch! Bye bye generic code. exactly one of the things that really bugged me with MATLAB! I thought MATLAB treated a single index as a flat index. So it yields a scalar no matter what (actually a 1x1 matrix no matter what, since it's all matrices in matlab). --bb ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/23 Ondrej Certik [EMAIL PROTECTED]: What is the plan with the release? There are some minor problems in the Debian package, some of which are fixed by the new release. I didn't fix those in Debian as I thought the new release is coming out. But if it's going to take let's say month or two, I'll fix the current Debian package now. The question is: what blocks the release of 1.1? The following tickets deserve attention: http://projects.scipy.org/scipy/numpy/ticket/750 http://projects.scipy.org/scipy/numpy/ticket/605 http://projects.scipy.org/scipy/numpy/ticket/551 http://projects.scipy.org/scipy/numpy/ticket/738 http://projects.scipy.org/scipy/numpy/ticket/743 http://projects.scipy.org/scipy/numpy/ticket/748 http://projects.scipy.org/scipy/numpy/ticket/751 http://projects.scipy.org/scipy/numpy/ticket/736 Further issues: - Alan's matrix indexing: x[0][0] for matrices currently yield x[0] Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: The question is: what blocks the release of 1.1? The following tickets deserve attention: http://projects.scipy.org/scipy/numpy/ticket/750 http://projects.scipy.org/scipy/numpy/ticket/605 http://projects.scipy.org/scipy/numpy/ticket/551 http://projects.scipy.org/scipy/numpy/ticket/738 http://projects.scipy.org/scipy/numpy/ticket/743 http://projects.scipy.org/scipy/numpy/ticket/748 http://projects.scipy.org/scipy/numpy/ticket/751 http://projects.scipy.org/scipy/numpy/ticket/736 Further issues: - Alan's matrix indexing: x[0][0] for matrices currently yield x[0] I was still hoping to get 1.1.0 out ASAP. Unfortunately, I have been too busy for the last week to pay attention to the release blockers. The last time I looked the only issues I felt absolutely needed to be resolved before the release were: 1. Testing the Windows binary, which is now done. 2. Testing the Mac binary, which is now done. 3. Testing or removing fromregex, which is now done: http://projects.scipy.org/scipy/numpy/ticket/719 I haven't looked carefully at the above tickets, but at a cursory glance it didn't seem like there were any new regressions. Stefan could you confirm that? If so, I would like to branch 1.1.x and tag 1.1.0 on Friday night. Unless there is some concrete reason that we need to delay this release any longer, I will send out an email later today with an 'official' timeline for the release, which will probably be on Monday if I tag on Friday night. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Hi Jarrod Of those tickets, the following are serious: http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is available?, David Huard) Fixing of histogram. http://projects.scipy.org/scipy/numpy/ticket/551 (old regression, Chuck and Travis) Unpickled arrays don't work as expected, because of memory alignment issues. http://projects.scipy.org/scipy/numpy/ticket/748 (old regression, Stefan) ifft pads incorrectly. I can fix this tonight, if someone would verify that this is, indeed, a bug. http://projects.scipy.org/scipy/numpy/ticket/751 (old/new regression, Stefan, David C*) ALL section not recognised in site.cfg. In Python 2.6, the DEFAULT section no longer works. I replaced it with ALL, but apparently not everything works as expected. David has a way to reproduce the problem, so I hope he can have a look, otherwise I'll try and fix it tomorrow. Regards Stéfan 2008/4/23 Jarrod Millman [EMAIL PROTECTED]: On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: The question is: what blocks the release of 1.1? The following tickets deserve attention: http://projects.scipy.org/scipy/numpy/ticket/750 http://projects.scipy.org/scipy/numpy/ticket/605 http://projects.scipy.org/scipy/numpy/ticket/551 http://projects.scipy.org/scipy/numpy/ticket/738 http://projects.scipy.org/scipy/numpy/ticket/743 http://projects.scipy.org/scipy/numpy/ticket/748 http://projects.scipy.org/scipy/numpy/ticket/751 http://projects.scipy.org/scipy/numpy/ticket/736 Further issues: - Alan's matrix indexing: x[0][0] for matrices currently yield x[0] I was still hoping to get 1.1.0 out ASAP. Unfortunately, I have been too busy for the last week to pay attention to the release blockers. The last time I looked the only issues I felt absolutely needed to be resolved before the release were: 1. Testing the Windows binary, which is now done. 2. Testing the Mac binary, which is now done. 3. Testing or removing fromregex, which is now done: http://projects.scipy.org/scipy/numpy/ticket/719 I haven't looked carefully at the above tickets, but at a cursory glance it didn't seem like there were any new regressions. Stefan could you confirm that? If so, I would like to branch 1.1.x and tag 1.1.0 on Friday night. Unless there is some concrete reason that we need to delay this release any longer, I will send out an email later today with an 'official' timeline for the release, which will probably be on Monday if I tag on Friday night. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On 23/04/2008, Alan Isaac [EMAIL PROTECTED] wrote: On Wed, 23 Apr 2008, Sebastian Haase wrote: What used to be referred to a the 1.1 version, that can break more stuff, to allow for a cleaner design, will now be 1.2 So ... fixing x[0][0] for matrices should wait until 1.2. Is that correct? It seems to me that everyone agrees that the current situation is broken, but there is considerable disagreement on what the correct fix is. My inclination is to apply the minimal fix you suggest, with tests and documentation, as a stopgap, and let the different factions sort it out by discussion on the way to 1.2. Objections? Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald [EMAIL PROTECTED] wrote: So ... fixing x[0][0] for matrices should wait until 1.2. Is that correct? It seems to me that everyone agrees that the current situation is broken, but there is considerable disagreement on what the correct fix is. My inclination is to apply the minimal fix you suggest, with tests and documentation, as a stopgap, and let the different factions sort it out by discussion on the way to 1.2. +1 That sound reasonable to me. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/23, Stéfan van der Walt [EMAIL PROTECTED]: Hi Jarrod Of those tickets, the following are serious: http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is available?, David Huard) Fixing of histogram. I haven't found a way to fix histogram reliably without breaking the current behavior. There is a patch attached to the ticket, if the decision is to break histogram. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Wed, 23 Apr 2008, Stéfan van der Walt wrote: Done in r5072. Much appreciated. I have updated URL:http://www.scipy.org/MatrixIndexing to reflect this change (and its provisional status). Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
Alan Isaac wrote: I have updated URL:http://www.scipy.org/MatrixIndexing to reflect this change (and its provisional status). Thanks for writing this up -- it really clarifies what's being proposed. A few comments on that write up: For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the array attribute of a Row Vector or Column Vector be 1d? Absolutely -- a vector is a 1-d array. The only difference here is that we can preserve the concept of a row vs. a column vector -- key to linear algebra, which is the whole point of the Matrix class. I'd be just as happy if a RowVector an ColumnVector were a more unique object -- a 1-d array with the operation overloaded, rather than a (1,n) or (n,1) matrix, but I understand that would be more work. Deviations from the behavior of ndarrays. Specifically, iteration over a matrix will not yield 1d NumPy arrays. Why should they? indexing a nested list gives a different result than indexing an ndarray, etc, etc, etc. The POINT of matrixes is that they are different! This proposal makes them a little more similar to ndarrays than the old behavior (always returning a matrix). Inconsistency in the indexing style for producing row vectors and column vectors not really: row vector: M[i,:] column vector: M[:,i] The fact that there is another way to get a row vector: M[i] is a bonus. I once proposed making M[i] raise an exception for the sake of enforcing consistency, but no one liked that! Loss of a standard way to extract a row or a column as a submatrix (rather than a vector) What's wrong with: M[i:i+1, :] and M[:, i:i+1] This is totally consistent with arrays (and other python sequences). Yes, it's a bit more awkward, but with the new vectors, it's also going to be needed far less. No clear gain in functionality over the simpler proposal 2. Well, I won't judge what's clear but I think this adds functionality. The concept of row and column vectors is a key part of linear algebra. Sure, you can model them as matrixes that happen to have only one row or one column, but that's what we had, but there seem to be real issues with use of that. Option (2), is Let a Matrix be a container of 1d arrays.. Sounds simple, but do those arrays represent row or column vectors? Either would make sense. The proposal is for them to be row vectors, which is fine, but then if you want them to act like a row vectors, do you need to convert them back into matrices? Even if not, how do you get a column vector -- by indexing the current way, and getting a (n,1) matrix, so that now we have inconsistency between how row and column vectors are treated -- not a clean API. And this is about a clean API for linear algebra -- otherwise, we'd just all use arrays (which many do!) Aside from the fact that someone needs to write the code -- why don't people like the row/column vector idea? It just feels so natural to me: A matrix is a 2-d array with some functionality overloaded to make it convenient to do linear algebra. A vector is a 1-d array with some functionality overloaded to make it convenient to do linear algebra. A scalar is the same in both contexts, so no need to change anything there. And yes, maybe this will lead to tensors some day! Another couple questions: -- would there be constructors for vectors? np.RowVector((1,2,3,4,5)) np.ColumnVector((1,2,3,4,5,6)) and would: A_RowVector.T == A_ColumnVector I would think so. One more note: All the example code I've seen during this discussion have been examples of iterating and indexing -- not one has actually been linear algebra -- perhaps we should see some of those before making any decisions. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
2008/4/23 Christopher Barker [EMAIL PROTECTED]: Aside from the fact that someone needs to write the code -- why don't people like the row/column vector idea? It just feels so natural to me: I wrote most of the code last week (see the previous thread on the mailing list for a patch). It currently only implements Vector (not RowVector and ColumnVector), but those two would be easy to add. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
[CHOP] The proposals thus far don't address two of the major issues I have with the matrix class: 1. The matrices and arrays should become more alike if possible and should share more of the same code base. From what I've seen, the people who write the code (for numpy) don't actually use matrices, they use the arrays. This is one of the main reasons matrices still have so many problems IMO; if one of the main developers were using them, they'd never have put up with it. This may be changing to some extent now, but the more we can make matrices and arrays share code and interface, the happier we'll be. None of the new rules strike me as helping in this arena and may in fact hurt. Again, IMO. 2. This doesn't support the concept of arrays of matrices/vectors, which is one thing I've always wanted out of the matrix class. For example it would be nice to be able to spell: 'A' is a 1D array of matrices (3D) overall, 'B' is a 1D array of vectors (3D) overall, matrix multiply them together, yielding a 1D array of matrices (3D) overall. I have frequently run into various permutations of this problem. You can fake it with loops over dot, but the efficiency is very bad for small arrays, plus it's ugly. I have lot's of vague ideas on this subject that have been floating around my head for the past couple of years. Basically, I think the way to go is to probably add some meta information to arrays that make them look a little bit more like tensors. Then, if one is careful (and things work out as I hope) matrices could be implemented as a thin layer on top of arrays. Or perhaps, if we are very lucky, done away with altogether. Anyway, that's all very vague and hand-wavey; if I can spring free some time, I'll try to write something up in the not too distant future. I'm glad to see that any major changes are being put off for a while: I think we should be able to do better than just patch up the old matrix class. -tim ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy release
Hi Jarrod, any news with the 1.0.5? If you have same prerelease, I'd like to test it. Debian has just moved from python2.4 to python2.5 yesterday, so I'd like to test numpy in advance, I am sure there will be some issues to fix. Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
