Re: [Numpy-discussion] Release of NumPy
On Tue, 15 Apr 2008, Anne Archibald apparently wrote: This discussion risks going around in circles. Write up your proposed solutions, with example code, in PEP style, here: http://www.scipy.org/ProposedEnhancements Done: http://www.scipy.org/MatrixIndexing I am a NumPy user, not a NumPy developer, but I believe the example code appropriately produces the desired behavior change. I believe this is really the last opportunity for this change. It is clear that it is already almost impossible to make API changes, even those that like this one are unlikely to affect much real code. So if it is a good idea, as I argue, its time has come. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 15/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: I thought the context of the discussion had become something like this: there is no reason for the matrix interface to deviate from the array interface except as needed to provide specific desired functionality. Essentially, - matrix multiplication - powers of square matrices - submatrix creation The proposal on the table is to remove an unneeded (and unwanted) deviation of the matrix API from the ndarray API. That is all. On Tue, 15 Apr 2008, Stéfan van der Walt apparently wrote: Unless my memory fails me (again), this would result in another deviation from numpy: that x[0] no longer returns the first row of any 2D array (matrix), especially when dealing with matrices of shape of (1,N). Either I do not understand you, or this is not correct, or... Anyway, for matrix x, x[0] should be the same as the current x.A[0] The whole issue occurs because a Matrix is not a proper container. Right. And *that* is the case because of the attempt to treat matrices as containers of matrices instead of as containers of 1d arrays. I can see no real advantage to having matrices be containers of row vectors instead. A row vector would just be a matrix (i.e., essentially 2d) that allowed 1d style indexing. Again I ask, have you ever needed such a thing? My favorite quote in these threads so far has to be by Charles Harris: All this for want of an operator ;) I agree this is a good perspective. (But *two* operators: * and **.) It implies: there are deviations from array behavior that are buying us nothing. This is my point. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: The whole issue occurs because a Matrix is not a proper container. Right. And *that* is the case because of the attempt to treat matrices as containers of matrices instead of as containers of 1d arrays. I can see no real advantage to having matrices be containers of row vectors instead. A row vector would just be a matrix (i.e., essentially 2d) that allowed 1d style indexing. Again I ask, have you ever needed such a thing? In the Matrix world, there is no such thing as an (N,) array -- which is why the current Matrix object behaves so strangely, and always returns a result with ndim 1. Your proposal suggests that a Matrix be a container of arrays, but it does not address the slicing of column vectors, i.e. x[0] x[0,:] x[:,0] would then behave in completely different ways, whereas with ndarrays they don't. If you modified the proposal to say any slicing operation that returns a (1,N) or (N,1) matrix should now return an (N,) ndarray, it would be more consistent, but then, wouldn't that break some other expected behaviour? I thought one of the powerful features of a matrix is that it preserves the orientation of a vector slice? The only way I've seen so far to have consistent slicing, is to have an N-dim Matrix object be a container of N-1 dim Matrices, up to the 2-D case, in which it becomes a container of Vectors which, in turn, contain scalars. I agree this is a good perspective. (But *two* operators: * and **.) It implies: there are deviations from array behavior that are buying us nothing. This is my point. Yup, and fortunately we now have both those implemented for arrays as well :) Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: On 16/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: The whole issue occurs because a Matrix is not a proper container. Right. And *that* is the case because of the attempt to treat matrices as containers of matrices instead of as containers of 1d arrays. I can see no real advantage to having matrices be containers of row vectors instead. A row vector would just be a matrix (i.e., essentially 2d) that allowed 1d style indexing. Again I ask, have you ever needed such a thing? In the Matrix world, there is no such thing as an (N,) array -- which is why the current Matrix object behaves so strangely, and always returns a result with ndim 1. Your proposal suggests that a Matrix be a container of arrays, but it does not address the slicing of column vectors, i.e. x[0] x[0,:] x[:,0] would then behave in completely different ways, whereas with ndarrays they don't. If you modified the proposal to say any slicing operation that returns a (1,N) or (N,1) matrix should now return an (N,) ndarray, it would be more consistent, but then, wouldn't that break some other expected behaviour? I thought one of the powerful features of a matrix is that it preserves the orientation of a vector slice? The only way I've seen so far to have consistent slicing, is to have an N-dim Matrix object be a container of N-1 dim Matrices, up to the 2-D case, in which it becomes a container of Vectors which, in turn, contain scalars. I don't think of arrays as containers of anything but scalars, so I find this whole argument from intuition extremely strange. My (draconian) suggestion would be to simply raise an exception when a matrix is indexed with a scalar. They're inherently two-dimensional; if you want a submatrix you should provide both indices (possibly including a :). If you actually want a subarray, as with an array, use .A. That said, I don't actually use matrices, so I don't get a vote. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Anne Archibald [EMAIL PROTECTED] wrote: I don't think of arrays as containers of anything but scalars, so I find this whole argument from intuition extremely strange. I see now for the first time that Matrices can't have dims 2. Grim. I do think that ColumnVector and RowVector could be useful in general; some statements read more clearly, e.g. (for x an (N,)-array) ColumnVector(x) instead of np.c_[x] # turn x into a column vector And, while np.dot(x,x) is valid, RowVector(x) * ColumnVector(x) is clearer than x = np.dot(np.r_[x], np.c_[x]) (which is a pattern I'd expect to find amongst linear algebra users) The last expression also yields array([14]) instead of 14! My (draconian) suggestion would be to simply raise an exception when a matrix is indexed with a scalar. They're inherently two-dimensional; if you want a submatrix you should provide both indices (possibly including a :). If you actually want a subarray, as with an array, use .A. Your idea isn't that far out -- but I think we can provide the expected (ndarray-like) behaviour in this case. That said, I don't actually use matrices, so I don't get a vote. Apparently, neither do I :) But I do get to modify http://www.scipy.org/MatrixIndexing I also changed ProposedEnhancements into a Category page, that automatically accumulates all WikiPages tagged with ProposedEnhancements. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Py3K
This looks like something that need to go on a list for numpy 1.2. Can you post a list of the specific problems that need to be addressed?Chuck Maybe this post can give some hints: All Things Pythonic Python 3000 and You by Guido van Rossum March 17, 2008 Summary I've posted the slides from my PyCon 2008 keynote on python.org. Here are the URLs, plus a warning against the temptation of changing your APIs at the same time as porting to Py3k. This is really important! http://www.artima.com/weblogs/viewpost.jsp?thread=227041 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
Apologies for coming out of the woodwork so late here..
For blas/atlas etc in numpy scipy on an opteron I use the AMD
libraries (which only have fblas) together with cblas. This works very
well.
Current-ish SVN (v4779) in line 295-296 of numpy/core/setup.py has:
if ('NO_ATLAS_INFO',1) in blas_info.get('define_macros',[]):
return None # dotblas needs ATLAS, Fortran compiled
blas will not be sufficient
To get my AMD fblas/cblas approach to work, I have to comment out
these two lines.
Can this restriction preventing use of AMD fblas be removed for v1.1?
Should I file a bug here?
Regards, George Nurser.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Py3K
On 16/04/2008, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 1:27 PM, Charles R Harris Oh, and making the transition will be made a lot easier by having a complete set of tests. Getting the tests and documentation into good state might be the best focus for our 1.2 effort. +1 Bonus points for whoever adds coverage reporting to our test suite, so that we can get at least basic metrics of coverage by: - docstrings - doctests - plain tests I'd love to see that. In the meantime, here is a figleaf coverage report: http://mentat.za.net/numpy/coverage/ Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Py3K
Tim Michelsen wrote: This looks like something that need to go on a list for numpy 1.2. Can you post a list of the specific problems that need to be addressed?Chuck Maybe this post can give some hints: All Things Pythonic Python 3000 and You by Guido van Rossum March 17, 2008 Summary I've posted the slides from my PyCon 2008 keynote on python.org. Here are the URLs, plus a warning against the temptation of changing your APIs at the same time as porting to Py3k. This is really important! http://www.artima.com/weblogs/viewpost.jsp?thread=227041 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Hi, As Guido highlights in his sides (linked from his blog), the Python 2.6 series has a flag (-3) to help porting. So I would suggest that Python 2.6 compatibility would be an first intermediate step . I have the suspicion that some of the 'small' changes are going to be very important and hard to track down without checking that is works in Python 2.6. Bruce ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
George Nurser wrote:
Apologies for coming out of the woodwork so late here..
For blas/atlas etc in numpy scipy on an opteron I use the AMD
libraries (which only have fblas) together with cblas. This works very
well.
Current-ish SVN (v4779) in line 295-296 of numpy/core/setup.py has:
if ('NO_ATLAS_INFO',1) in blas_info.get('define_macros',[]):
return None # dotblas needs ATLAS, Fortran compiled
blas will not be sufficient
To get my AMD fblas/cblas approach to work, I have to comment out
these two lines.
Can this restriction preventing use of AMD fblas be removed for v1.1?
Should I file a bug here?
Yes, you should put a ticket together. The more information you can
provide, the more likely someone will act on the ticket. Some kind of
info on why you had to comment out those two lines would be helpful.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote: Your proposal suggests that a Matrix be a container of arrays, but it does not address the slicing of column vectors, i.e. x[0] x[0,:] x[:,0] The only thing that changes is the handling of scalar indices (and thus of iteration). The other two cases remain unchanged. This should be clear from the proposal: http://www.scipy.org/MatrixIndexing The rule is: to get a submatrix, use multiple indices. As Anne has argued, this is natural. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Py3K
On Wed, Apr 16, 2008 at 2:56 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: On 16/04/2008, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 1:27 PM, Charles R Harris Oh, and making the transition will be made a lot easier by having a complete set of tests. Getting the tests and documentation into good state might be the best focus for our 1.2 effort. +1 Bonus points for whoever adds coverage reporting to our test suite, so that we can get at least basic metrics of coverage by: - docstrings - doctests - plain tests I'd love to see that. In the meantime, here is a figleaf coverage report: http://mentat.za.net/numpy/coverage/ Wow, figleaf is really cool. I didn't know about this tool. Ondrej ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Anne Archibald apparently wrote: My (draconian) suggestion would be to simply raise an exception when a matrix is indexed with a scalar. This has been suggested before. But then, why? Again, this imposes a deviation from the behavior of arrays that provides no gain in functionality. My proposal is: deviate from array behavior only when it gives a clear gain in functionality. They're inherently two-dimensional; Of course. But the question is what follows from this as an implication for the behavior of 1d indexing and iteration. The answer is: nothing! We get to do whatever is most useful! if you want a submatrix you should provide both indices (possibly including a :). Yes. We exactly agree on this. Please persuade Stefan. If you actually want a subarray, as with an array, use .A. Again we agree on this. But none of this answers the question: what should you get when you iterate over a matrix. Stefan seems to agree with me to this extent: we should get its rows. This disagreement is over what that means: are these submatrices, a new vector object, or 1d arrays? I claim that if you use matrices, you will find it natural for these to be 1d arrays. That said, I don't actually use matrices, so I don't get a vote. As far as I know, no objections have been raised by users of matrices. In this sense, the objections have all been abstract: they do not reflect experience with the implied convenience or inconvenience or particular behaviors. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Apr 15, 2008, at 11:41, Gael Varoquaux wrote: On Tue, Apr 15, 2008 at 01:38:45AM -0500, Robert Kern wrote: Given that the next release will be 1.1, I think it is reasonable to include a few additional API breaks. -lots. I don't want to break API compatibility again no matter what version number we bump to, 1.1, 2.0, or 24. It is simply not okay to do this again and again. +1 with Robert. +1 with Robert as well. My code still uses the oldnumeric API, so I am not directly concerned by changes to the new one, but I'd like to be able to move to the new API one day but most definitely only ONCE. Konrad. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, Apr 16, 2008 at 8:06 AM, Alan G Isaac [EMAIL PROTECTED] wrote: On Wed, 16 Apr 2008, Anne Archibald apparently wrote: My (draconian) suggestion would be to simply raise an exception when a matrix is indexed with a scalar. This has been suggested before. But then, why? Again, this imposes a deviation from the behavior of arrays that provides no gain in functionality. My proposal is: deviate from array behavior only when it gives a clear gain in functionality. They're inherently two-dimensional; Of course. But the question is what follows from this as an implication for the behavior of 1d indexing and iteration. The answer is: nothing! We get to do whatever is most useful! if you want a submatrix you should provide both indices (possibly including a :). Yes. We exactly agree on this. Please persuade Stefan. If you actually want a subarray, as with an array, use .A. Again we agree on this. But none of this answers the question: what should you get when you iterate over a matrix. Stefan seems to agree with me to this extent: we should get its rows. This disagreement is over what that means: Just to make things interesting, if one uses rows (covariant) and column (contravariant) vectors, then there are lots of ways of looking at matrices. A covariance matrix, for instance, is a sum of tensor products of two column vectors, its inverse of row vectors, and a normal linear transformation is the sum of tensor products of column and row vectors. This all makes good mathematical sense and is like tracking units. That is, it isn't done in most numerical software ;) And remember, covariant and contravariant are reversed from their usual meaning due to historical accident. Next up, tensors as a subtype of ndarrays! Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: The rule is: to get a submatrix, use multiple indices. As Anne has argued, this is natural. That is *not* the rule for arrays; you argued the compatibility point yourself. As far as I know, no objections have been raised by users of matrices. I haven't seen many comments either way. Are you opposed to fixing the problem the way Tim suggested? I claim that if you use matrices, you will find it natural for these to be 1d arrays. Why would linear algebra users prefer 1d arrays instead of vectors? Attached, please find a first attempt at implementing a Vector class. It passes all tests on my machine. Regards Stéfan numpy_mat_vector.patch Description: Binary data ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, Apr 16, 2008 at 10:06:05AM -0400, Alan G Isaac wrote: if you want a submatrix you should provide both indices (possibly including a :). Yes. We exactly agree on this. Please persuade Stefan. Alan, instead of trying blindly to persuade Stefan, please listen to his arguments. Or code an example implementation and show it to us. Stefan, and incidently myself, believe your position cannot be described in a consistent way, and that the day you try to code it, it will fall down. This is why the RowVector and ColumnVector idea was proposed. For me it is the only consistent proposal I have heard so far. I don't care that much about all this, but I do care that you are trying to get developpers lose their time on something that cannot work. But none of this answers the question: what should you get when you iterate over a matrix. Stefan seems to agree with me to this extent: we should get its rows. This disagreement is over what that means: are these submatrices, a new vector object, or 1d arrays? I claim that if you use matrices, you will find it natural for these to be 1d arrays. OK, let us pretend A[:, 1] returns a 1D array, as you seem to be wanting, (A and B are matrices), What is A[1, :] * B then? You are multiply an array with a matrix. That already is dodgy, but numpy deals with it, and you get what you want. What about B*A[:, 1]? You don't get what you want here. So you have broken the user's expectation once again. The question is should we break this expectation (1), the expectation that A[x][y] = A[x, y] (2), or add RowVector and ColumnVector (3)? I believe that 3 is better than 2, which is better than 1. By the way, I think this has already been discussed. Let us not have the discussion go in circles, and try to keep in mind the different arguments. Maybe I am wrong, and you can make this work in a consistent way. In this case prove me wrong, and write some demo code that does this. The numpy developpers can than work with you to adapt it to a patch for numpy, and it can go in. That said, I don't actually use matrices, so I don't get a vote. As far as I know, no objections have been raised by users of matrices. In this sense, the objections have all been abstract: they do not reflect experience with the implied convenience or inconvenience or particular behaviors. I have seen many times users ask for langage features that break its consistency, just because they do not realize it. The fact that you can use a language doesn't mean that you are skilled-enough to invent one. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Gael Varoquaux wrote: let us pretend A[:, 1] returns a 1D array, as you seem to be wanting Where did I say anything like that?? Please look at the proposal. It affects **only** scalar indexing (and thereby iteration). Recall how emphatically I agreed with you: Multiple indexes should always return submatrices, and the right way to get submatrices is with multiple indexes. I have proposed no change in the behavior of non-scalar indexes. None. I specify an actual code change on the page you asked me to create. It is a trivial change in __getitem__. It does not lead to any of the breakage you suggest, because it does not change the behavior you consider. Please look: it changes *only* the processing of a scalar index. Since I'm not familiar with NumPy internals, I offer this only to pin down what I am talking about, not as a proposed code change. But it should make it clear that I am not asking what you suggest. AND (!!) my proposed change means that A[x][y] == A[x, y] which is not currently true. One good thing has come out of this discussion: as far as I can tell, everyone agrees that there should be a change such that A[x][y] == A[x, y] I believe I am proposing the simplest change, which leaves matrices as much like ndarrays as possible. My main objection to Stefan's proposal is that it adds substantial complexity for no apparent gain. Charles may have been suggesting that he can see a substantial gain: his comment was too cryptic for me. If so, I would be interested. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: The rule is: to get a submatrix, use multiple indices. On Wed, 16 Apr 2008, Stéfan van der Walt wrote: That is not the rule for arrays; you argued the compatibility point yourself. Sorry, I do not understand. I am saying only: I propose no change in current matrix behavior in response to nonscalar indexes. On Wed, 16 Apr 2008, Stéfan van der Walt wrote: Are you opposed to fixing the problem the way Tim suggested? It seems lots of complexity for a payoff I do not see. My proposal is simpler and stays closer to ndarray behavior. But having a matrix be a container of such RowVectors is better than the current behavior. I do not see that it gets in the way of anything desirable, as long as the array attribute of your vectors will return a 1d array. Why would linear algebra users prefer 1d arrays instead of vectors? What is a vector? To me a vector is an element of a vector space. As far as I can tell, a 1d array *is* a vector. If you mean by vector what people mean when they say row vector or column vector, this is just short hand for special matrices. If I want these special matrices, I can have them right now. Of course I cannot index the elements with a scalar... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
Hi Robert On 16/04/2008, Robert Kern [EMAIL PROTECTED] wrote: The correct fix needs to be more sophisticated than removing those two lines. We need to recognize the MKL and the GOTO BLAS and allow them, too. It might also be worth including the appropriate subset of the cblas code provided in the tarball such that we can use any accelerated FORTRAN BLAS without the standard cblas interface. Then George wouldn't have the build the cblas library himself, either. The inclusion of those cblas routines sounds like a good idea. Could you describe which we need, and what would be required to get this done? Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] OSX installer: please test
I've built a Universal Mac binary for numpy 1.1.0. If Mac people would kindly test it, I'd appreciate any feedback. Download here: https://cirl.berkeley.edu/numpy/numpy-1.1.0rc1-py2.5-macosx10.5.dmg Technical details: - Built on OSX 10.5.2, Intel Core 2 Duo - Using XCode 3.0 with gcc 4.0.1 and the Accelerate.framework 1.4.2, gfortran 4.2.1 and Python 2.5.2 from python.org (MacPython) - Used bdist_mpkg 0.4.3 to make the distribution Since it uses the MacPython, it will install numpy under here: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages Thanks -- Christopher Burns 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 setup.py too restrictive, prevents use of fblas with cblas
On Wed, Apr 16, 2008 at 3:37 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Hi Robert On 16/04/2008, Robert Kern [EMAIL PROTECTED] wrote: The correct fix needs to be more sophisticated than removing those two lines. We need to recognize the MKL and the GOTO BLAS and allow them, too. It might also be worth including the appropriate subset of the cblas code provided in the tarball such that we can use any accelerated FORTRAN BLAS without the standard cblas interface. Then George wouldn't have the build the cblas library himself, either. The inclusion of those cblas routines sounds like a good idea. Could you describe which we need, and what would be required to get this done? Basically all of the files defining functions used in _dotblas.c and their dependencies; grepping for cblas_ should find them all. The tricky part, naturally, is the build configuration. We need to recognize when we have an accelerated fblas and cblas (do not use our own cblas routines), when we have an accelerated fblas only (do use our own cblas routines), and when we don't have anything accelerated (do not build dotblas at all). I don't have a particularly clear idea on how to do that cleanly. One potential problem that I've just noticed is that there are some Fortran files in the cblas. For the most part, these seem to be used to convert Fortran function calls which return complex scalars to Fortran subroutines which can be easily interfaced to C. For example cblas_cdotu_sub.c requires cdotc.f. dotblas uses four such functions: cblas_[cz]dot[cu]_sub(). We would have to find another way to do these; possibly, we can just apply f2c to the Fortran files. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
On Mittwoch 16 April 2008, Stéfan van der Walt wrote: The inclusion of those cblas routines sounds like a good idea. Could you describe which we need, and what would be required to get this done? Suppose cblas gets included in numpy, but for some reason someone decides to link another copy of cblas with their (separate) extension. Can we be certain that this does not lead to crashes on any platform supported by numpy? Andreas signature.asc Description: This is a digitally signed message part. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote: Do you think that a (column) vector should convert to a 1d array? Yes: for consistency with row vector conversion, and for indexing consistency. Again, I understand what you have done, and it addresses my core issue. I do not object to it. I just think there is a better way. (Better = simpler and just as functional.) I strongly support your proposal over no change. I just do not think it is a better proposal. But frankly I am not even sure of that: I see some pedagogical advantages in your approach, and I think Charles suggested that it may enable some new functionality. (But what is that?) In sum: if you put this in NumPy, I will happy. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote: I showed you exactly where your proposal breaks down -- numerous times: x[0] is no longer the same as x[0,:] And as I explained back: this is a good thing (TM). There is no need for these to be the same. I also gave you the simple rule for users to rely on: nonscalar indexes are used for submatrix extraction. It is not a breakdown. It is the proposal: restore the proper behavior of x[0], but keep submatrix extraction **exactly** the same as it is now (for nonscalar indexes). What it gains is that x[i][j] == x[i,j]. Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
On Wed, Apr 16, 2008 at 4:56 PM, Andreas Klöckner [EMAIL PROTECTED] wrote: On Mittwoch 16 April 2008, Stéfan van der Walt wrote: The inclusion of those cblas routines sounds like a good idea. Could you describe which we need, and what would be required to get this done? Suppose cblas gets included in numpy, but for some reason someone decides to link another copy of cblas with their (separate) extension. Can we be certain that this does not lead to crashes on any platform supported by numpy? I imagine we would have the same problem with the f2c'ed default LAPACK routines we include to support numpy.linalg. I haven't heard of this ever causing a problem. However, if there is a conflict, we can get around it with clever #defines such that the actual symbols in the extension module would be, say, numpy_cblas_dgemm, etc. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 17/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: It is not a breakdown. It is the proposal: restore the proper behavior of x[0], but keep submatrix extraction **exactly** the same as it is now (for nonscalar indexes). What it gains is that x[i][j] == x[i,j]. As the patch I sent earlier shows, we can gain that without compromising on x[0] == x[0,:]. The Vector class can be tweaked further in how it is converted to an array. It would be easy to produce a 1d-array -- and there's some argument for consistency there. I don't want you to feel that I steam-rollered your proposal, though, so before I commit I'd like for someone to objectively take a look at both approaches/patches and comment. Goodnight, Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, Apr 16, 2008 at 06:02:53PM -0400, Alan G Isaac wrote: On Wed, 16 Apr 2008, Stéfan van der Walt apparently wrote: I showed you exactly where your proposal breaks down -- numerous times: x[0] is no longer the same as x[0,:] And as I explained back: this is a good thing (TM). There is no need for these to be the same. [...] What it gains is that x[i][j] == x[i,j]. I am sorry, I don't see why you prioritize x[i][j] == x[i,j] (1) more than x[0] == x[0,:] (2). For me it is the other way around, because we should be encouraging users not to use x[i][j], which is a very poor way of indexing compared to x[i,j]. The first requires two __getitem__ calls and an object creation, whereas the first requires only one, and no object creation. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 17/04/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: On 17/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: It is not a breakdown. It is the proposal: restore the proper behavior of x[0], but keep submatrix extraction **exactly** the same as it is now (for nonscalar indexes). What it gains is that x[i][j] == x[i,j]. As the patch I sent earlier shows, we can gain that without compromising on x[0] == x[0,:]. The Vector class can be tweaked further in how it is converted to an array. It would be easy to produce a 1d-array -- and there's some argument for consistency there. I don't want you to feel that I steam-rollered your proposal, though, so before I commit I'd like for someone to objectively take a look at both approaches/patches and comment. Split infinitive -- I'd get in trouble for that. Please use the latest patch (attached), which fixes a bug with assignment. I experimented with returning an (N,) array when converting using vector.A, but I'm not convinced that that is consistent behaviour, so I let that issue remain for now. Cheers Stéfan numpy_mat_vector_01.patch Description: Binary data ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Thu, 17 Apr 2008, Gael Varoquaux apparently wrote: I am sorry, I don't see why you prioritize x[i][j] == x[i,j] (1) more than x[0] == x[0,:] (2). Well the quick answer is: use matrices for awhile, and I expect you will see why, and teach them for awhile, and I am quite sure you will see why. But to provide some explanation. The underlying issue is not quite whether ``x[i][j] == x[i,j]``, but whether ``x[i][j]`` accesses the i,j-th element. The is a *fundamental* expectation for Python 2d containers. Naturally we can eventually train people to expect anything, but since I teach people to use Python, I can tell you the current matrix behavior is a pain in the butt. *Everyone* is surprised by the outcome of ``x[i][j]`` when x is a matrix. (Ask yourself: weren't you the first time?) Surprises are bad. In contrast, expectations about how nonscalar indexing works are much less of a given. And this is especially so if one teaches matrices before arrays, which I generally do. (More people are familiar with matrices.) You can just teach people how nonscalar indexing produces submatrices. No sweat. Related to this, it is a *fairly* fundamental expectation that iteration over a 2d Python object will yield 1d objects. This very natural expectation is met by ndarrays but not currently by matrices. My proposal allows all these natural expectations to be met. Stefan's scores well too, so why do I prefer mine? As I said, I am not sure mine is better, but I think it is, an I can offer some reasons to prefer it. Two are: - it is simpler - it retains more ndarray behavior Simplicity is always good, for any given level of functionality. Keeping close to ndarray behavior is good, since it means more transferable skills across the two types. A third more personal reason is essentially aesthetic. I like it when containers of a single type implement containment as a weak order in the type hierarchy. So I like that the less primitive matrix object would be a container of more primitive ndarrays (when iterating). Similarly, I like that ndarrays are containers of ndarrays. In contrast Stefan's implementation will treat matrices as containing a matrix subclass---a *less* primitive object, in this sense. I certainly do not expect others to share this preference, and I offer it up in expectation that it will garner some harsh criticism. But there it is. So that is my explanation. But again, if Stefan implements his proposal (tweaked as discussed), I will be quite pleased. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
Alan G Isaac wrote: On Thu, 17 Apr 2008, Gael Varoquaux apparently wrote: I am sorry, I don't see why you prioritize x[i][j] == x[i,j] (1) more than x[0] == x[0,:] (2). Well the quick answer is: use matrices for awhile, and I expect you will see why, and teach them for awhile, and I am quite sure you will see why. I have mixed feelings on all of this discussion. I do want to make sure, however, that two ideas are considered: 1) How will sparse matrices behave? It seems to me that the matrix object and sparse matrices should behave identically if at all possible. 2) How much code will break if we change the current behavior. Regarding (1), What does x[0] return when x is a sparse matrix? -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
