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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[hidden email]> wrote:
> 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. 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. Thanks, Ondrej _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
2008/4/23 Ondrej Certik <[hidden email]>:
> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Ondrej Certik
On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[hidden email]> wrote:
> On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[hidden email]> wrote: > > 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. > > 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 problem is, that it was noticed that non-backwards compatible changes were committed into svn. Most noticeably a complete rewrite of the "ma" (Masked Array) package was done. As a consequence it was decided, they no one would be interested in "temporarily taking those changes out" "just to release 1.0.5". Instead the next release will be called 1.1 -- which is (only; rather still) "mostly" compatible with 1.0.x 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 HTH, Sebastian Haase _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
On Wed, Apr 23, 2008 at 4:56 PM, Sebastian Haase <[hidden email]> wrote:
> > On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[hidden email]> wrote: > > On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[hidden email]> wrote: > > > 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. > > > > 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 problem is, that it was noticed that non-backwards compatible > changes were committed into svn. > Most noticeably a complete rewrite of the "ma" (Masked Array) package was done. > As a consequence it was decided, they no one would be interested in > "temporarily taking those changes out" "just to release 1.0.5". > > Instead the next release will be called 1.1 -- which is (only; rather > still) "mostly" compatible with 1.0.x > 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 OK, so I think we are going to try to fix the package in Debian right now and not wait for the release. I think this uncertainty about releases and about backward compatibility is not good. The same about uncertainty where f2py is going to end up. But you know the drill "talk is cheap, show me the code", so I know I could step up and help Jarrod with the release, but unfortunately, I don't have time for it. :) Ondrej _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Stéfan van der Walt
On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt <[hidden email]> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
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 <[hidden email]>: > On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt <[hidden email]> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Sebastian Haase
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? Thank you, Alan Isaac _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
On 23/04/2008, Alan Isaac <[hidden email]> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
<[hidden email]> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Stéfan van der Walt
2008/4/23, Stéfan van der Walt <[hidden email]>: Hi Jarrod 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Jarrod Millman
2008/4/23 Jarrod Millman <[hidden email]>:
> On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald > <[hidden email]> 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. Done in r5072. Cheers Stéfan _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
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/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [hidden email] _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
On Apr 23, 2008, at 3:55 PM, Christopher Barker wrote:
>> 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. The way I envisioned this was that RowVector and ColumnVector would inherit from Matrix, so that you would inherit all of the Matrix functionality. They would just be special cases where ncol=0 or nrow=0, allowing single indexing. If Matrix-Matrix multiplication is implemented properly, then the Row/ ColumnVector multiplication operators should automatically work. >> Inconsistency in the indexing style for producing row vectors and >> column vectors > > not really: I agree with Alan here. M[i] returns a RowVector, but there is no corresponding single index way to retrieve a ColumnVector (unless we want to use __call__() to make M(j) return a ColumnVector . . . but this is highly unintuitive.) Thinking out loud: we could support M[i=#] return a RowVector M[j=#] return a ColumnVector M[#] equivalent to M[i=#] > The fact that there is another way to get a row vector: M[i] is a > bonus. Except that the behavior of M[i] is one of the driving issues of the conversation. >> Loss of a standard way to extract a row or a column as a submatrix >> (rather than a vector) If Row/ColumnVector inherit from Matrix, then this is not strictly true. There is no reason that these classes could not support [i,j] indexing, which means they would BE Matrices (inheritence) and they would BEHAVE like Matrices (except for V[i][j] . . . argh). >> No clear gain in functionality over the simpler proposal 2. Gains: (1) non-scalar extractions from linear algebra objects ARE and BEHAVE like linear algebra objects; (2) a clear path for dense and sparse matrices to have the same (or at least analogous) interfaces. > 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: Unless I'm misremembering, Alan is the only one who has expressed concerns and he is willing to concede to the design if others agree. > 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. Again, I would argue for Vectors inheriting from Matrix. I would make the case based on code reuse and elegance, although these might be overridden by some other concern. > And yes, maybe this will lead to tensors some day! Don't see why not. > Another couple questions: -- would there be constructors for vectors? > > np.RowVector((1,2,3,4,5)) > np.ColumnVector((1,2,3,4,5,6)) Yes. They should be full-fledged classes, although with inheriting from Matrix, the implementation should be relatively small. What about np.Matrix(<container of RowVector>) np.Matrix(<container of ColumnVector>) ? > and would: > A_RowVector.T == A_ColumnVector Yes. > 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. Right. I have generally thought about this in the context of, say, a Krylov-space iterative method, and what that type of interface would lead to the most readable code. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: [hidden email] ** _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Chris Barker - NOAA Federal
2008/4/23 Christopher Barker <[hidden email]>:
> 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by wfspotz-sandia
[CHOP] The proposals thus far don't address two of the major issues I have with the matrix class:
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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by wfspotz-sandia
On Wed, 23 Apr 2008, Bill Spotz apparently wrote:
> Gains: (1) non-scalar extractions from linear algebra > objects ARE and BEHAVE like linear algebra objects; I believe this is not a gain, since there is a standard way to do this now, which would remain under the second proposal. > (2) a clear path for dense and sparse matrices to have the > same (or at least analogous) interfaces. This may prove true. I'm agnostic. What actually turns on this? I believe it is the following: if iterating over a sparse matrix yields sparse vectors that behave like a sparse matrix, then iterating over a matrix should return a vector that behaves like a matrix. But I have not seen any detailed discussion of this design issue. E.g., iterating over a sparse matrix could yield instead a sparse object that behaves like a 1d array. I should add that if the first approach is taken, I agree that it is natural for these "vectors" to inherit from matrix. With respect to the matrix object, my only "objection" has been that I'd like to hear someone state clearly what functionality is gained by following the more complex first proposal instead of the second proposal. The reason: the cost of complexity should be justified by a gain in functionality. It *may* be that the link between the behavior of matrices and that of sparse matrices is where the gain manifests, but that is not yet clear to me. > Unless I'm misremembering, Alan is the only one who has > expressed concerns and he is willing to concede to the > design if others agree. I'm in no position to concede or not concede anything, since I am not writing code, but my core concerns will be met by either proposal. Thanks! Alan _______________________________________________ Numpy-discussion mailing list [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Tim Hochberg
+1 Nadav -----הודעה מקורית----- מאת: [hidden email] בשם Timothy Hochberg נשלח: ה 24-אפריל-08 04:16 אל: Discussion of Numerical Python נושא: 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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat (6K) Download Attachment |
2008/4/24 Nadav Horesh <[hidden email]>:
> +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 [hidden email] http://projects.scipy.org/mailman/listinfo/numpy-discussion |
Free forum by Nabble | Edit this page |