Hi everybody. Sorry for such a basic question, or maybe two: shouldn't c_[...] result in something like array([ [ . ], [ . ] ]) while r_ results in array([ ... ]) ? why does: In [23]: a = r_[1:3:5j] In [24]: b = c_[2:6:5j] In [25]: b Out[25]: array([ 2., 3., 4., 5., 6.]) In [26]: a Out[26]: array([ 1. , 1.5, 2. , 2.5, 3. ]) In [27]: transpose a -------> transpose(a) Out[27]: array([ 1. , 1.5, 2. , 2.5, 3. ]) In [28]: transpose b -------> transpose(b) Out[28]: array([ 2., 3., 4., 5., 6.]) not allow transposition in the above mentioned way? And: if I got some functions that might be useful to others, and want to contribute them, where do I turn to? I got some interp2() function, modeled after (translated from) the octave algorithm, and a polyfit() more or less woven from same wool... Also I had to implement a Log-likelyhood fitting algorithm, and with some work it could be generalized to be included in scipy, and there's a 2d-integral() on a grid of given surface. I'm working in high-energy physics, and found out, what a beatiful tool for algorithm prototyping scipy can be... AND I think (and one of my colleagues knows already ;) it will work even better in data-analysis, together with the bindings to ROOT (PyROOT) - http://root.cern.ch where Python can provide a really reasonable shell and scripting environment, instead of ROOT's C++ interpreter(!!!), and scipy can do the necessary data manipulations. Cheers, Gerald. -- Gerald Richter <richter@hephy.oeaw.ac.at> phone: +43 1 5447328/27 Institute of high energy physics (HEPHY) http://wwwhephy.oeaw.ac.at/ Vienna/Austria
Gerald Richter wrote:
Hi everybody.
Sorry for such a basic question, or maybe two:
shouldn't c_[...] result in something like array([ [ . ], [ . ] ]) while r_ results in array([ ... ]) ?
Probably. Travis will probably have to step in here and explain what they are supposed to do in this case.
why does:
In [23]: a = r_[1:3:5j]
In [24]: b = c_[2:6:5j]
In [25]: b Out[25]: array([ 2., 3., 4., 5., 6.])
In [26]: a Out[26]: array([ 1. , 1.5, 2. , 2.5, 3. ])
In [27]: transpose a -------> transpose(a) Out[27]: array([ 1. , 1.5, 2. , 2.5, 3. ])
In [28]: transpose b -------> transpose(b) Out[28]: array([ 2., 3., 4., 5., 6.])
not allow transposition in the above mentioned way?
transpose(a) only flips the order of the axes. For a rank-1 array, it just maps back to itself. Rank-1 arrays are neither strictly row-vectors or strictly column-vectors. If you want to ensure that they are row- or column-vectors, use the atleast_2d() function. In [7]: a = r_[1:3:5j] In [8]: a.shape Out[8]: (5,) In [9]: transpose(a).shape Out[9]: (5,) In [10]: c = atleast_2d(a) In [11]: c.shape Out[11]: (1, 5) In [13]: transpose(c).shape Out[13]: (5, 1) In [14]: c Out[14]: NumPy array, format: long [ [ 1. 1.5 2. 2.5 3. ]] In [15]: transpose(c) Out[15]: NumPy array, format: long [[ 1. ] [ 1.5] [ 2. ] [ 2.5] [ 3. ]]
And: if I got some functions that might be useful to others, and want to contribute them, where do I turn to?
For batting around the issue on the mailing list, you can post them here if they are small, or preferably put them on a website and post the url here. If you know where they ought to go in scipy, you can make a patch and submit it to the issue tracker. Assign the issue to me (rkern), and I'll make sure it gets dealt with. http://www.scipy.net/roundup/scipy/index
I got some interp2() function, modeled after (translated from) the octave algorithm, and a polyfit() more or less woven from same wool...
That's a little murky license-wise. We want to keep everything BSD-licensed, and I assume that the original sources for these functions are GPLed. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Gerald Richter wrote:
I got some interp2() function, modeled after (translated from) the octave algorithm, and a polyfit() more or less woven from same wool...
On Thu, 21 Oct 2004, Robert Kern apparently wrote:
That's a little murky license-wise. We want to keep everything BSD-licensed, and I assume that the original sources for these functions are GPLed.
I hope that in such circumstances Gerald will take the extra step of informing the author of the Octave function of his translation and, as a matter of politeness as well as of possible licensing issues, request permission to release this Python code under the BSD license. Ideally SciPy will have some arrangement for archiving such permissions. fwiw, Alan Isaac
Robert Kern wrote:
Gerald Richter wrote:
Hi everybody.
Sorry for such a basic question, or maybe two:
shouldn't c_[...] result in something like array([ [ . ], [ . ] ]) while r_ results in array([ ... ]) ?
Probably. Travis will probably have to step in here and explain what they are supposed to do in this case.
why does:
In [23]: a = r_[1:3:5j]
In [24]: b = c_[2:6:5j]
In [25]: b Out[25]: array([ 2., 3., 4., 5., 6.])
In [26]: a Out[26]: array([ 1. , 1.5, 2. , 2.5, 3. ])
In [27]: transpose a -------> transpose(a) Out[27]: array([ 1. , 1.5, 2. , 2.5, 3. ])
In [28]: transpose b -------> transpose(b) Out[28]: array([ 2., 3., 4., 5., 6.])
not allow transposition in the above mentioned way?
SciPy is early enough in it's development that the behavior of r_ and c_ could be changed without extensive grief at this point, if it was important to change them. The idea of r_ was to allow fast creation of arrays similar to what is available with MATLAB. I wanted a short, quick way to concatenate and generate arrays. For 1-d arrays, r_ and c_ are supposed to be exactly the same. It's only when you give them two dimensional arrays that they differ. Admittedly, I really like the one-dimensional array creation ability of r_ and I use it quite often. The two-dimensional array creation is not as good. bmat is intended to improve that some. I am open to any ideas about how to improve this. Perhaps, we just kill c_ and suggest something else (like an improved bmat) for building 2-d arrays quickly. But, your transpose question is resolved by recognizing that there is a difference between a rank-1 array and a rank-2 matrix (which can be a column or row). Perhaps we should have a mechanism (perhaps a row_[...]) that generates a rank-2 row vector very quickly. Ideas are welcome, -Travis
On Fri, 22 Oct 2004, Travis Oliphant apparently wrote:
The idea of r_ was to allow fast creation of arrays similar to what is available with MATLAB. I wanted a short, quick way to concatenate and generate arrays. For 1-d arrays, r_ and c_ are supposed to be exactly the same. It's only when you give them two dimensional arrays that they differ. Admittedly, I really like the one-dimensional array creation ability of r_ and I use it quite often. The two-dimensional array creation is not as good. bmat is intended to improve that some. I am open to any ideas about how to improve this. Perhaps, we just kill c_ and suggest something else (like an improved bmat) for building 2-d arrays quickly.
I find both r_ and c_ nice to have around. I would request a single change: that for 1-d arrays, one of them return transpose([x]) instead of x. (In my view, r_ should do this, but whatever.) fwiw, Alan
Alan G Isaac wrote:
On Fri, 22 Oct 2004, Travis Oliphant apparently wrote:
The idea of r_ was to allow fast creation of arrays similar to what is available with MATLAB. I wanted a short, quick way to concatenate and generate arrays. For 1-d arrays, r_ and c_ are supposed to be exactly the same. It's only when you give them two dimensional arrays that they differ. Admittedly, I really like the one-dimensional array creation ability of r_ and I use it quite often. The two-dimensional array creation is not as good. bmat is intended to improve that some. I am open to any ideas about how to improve this. Perhaps, we just kill c_ and suggest something else (like an improved bmat) for building 2-d arrays quickly.
I find both r_ and c_ nice to have around. I would request a single change: that for 1-d arrays, one of them return transpose([x]) instead of x. (In my view, r_ should do this, but whatever.)
This would be decidedly different behavior, because 1-d arrays are not 2-d arrays. I would be inclined to introduce another command to rapidly build 2-d row an/or column vectors as you describe instead of changing the 1-d array-creation facility of r_ -Travis
I find the idea to introduce something like row_ and col_ very convenient. Given that it does: row_[1:4:4j] = array[ [ 1, 2, 3, 4 ] ] col_[1:4:4j] = array[ [ 1 ], [ 2 ], [ 3 ], [ 4 ] ] also, it seems reasonable, to provide something that does convert any 1-d object to the desired columns or row-shape a = ( 1,2,3) row(a) = array[ [ 1, 2, 3 ] ] ... similar for col() +++ I played arround a little with the functionality of c_ and r_ to understand it better... maybe these are examples to add to the documentation, so that it becomes more clear what these functions do? a = array([c_[1:4:4j]]) [ [ 1. 2. 3. 4.]] at = transpose(a) [[ 1.] [ 2.] [ 3.] [ 4.]] b = array([c_[5:8:4j]]) [ [ 5. 6. 7. 8.]] bt = transpose(b) [[ 5.] [ 6.] [ 7.] [ 8.]] c_[a,b] [ [ 1. 2. 3. 4. 5. 6. 7. 8.]] c_[at,bt] [[ 1. 5.] [ 2. 6.] [ 3. 7.] [ 4. 8.]] r_[a,b] [[ 1. 2. 3. 4.] [ 5. 6. 7. 8.]] r_[at,bt] [[ 1.] [ 2.] [ 3.] [ 4.] [ 5.] [ 6.] [ 7.] [ 8.]] greetings, Gerald On Fri, Oct 22, 2004 at 02:07:53PM -0600, Travis Oliphant wrote:
SciPy is early enough in it's development that the behavior of r_ and c_ could be changed without extensive grief at this point, if it was important to change them.
The idea of r_ was to allow fast creation of arrays similar to what is available with MATLAB. I wanted a short, quick way to concatenate and generate arrays. For 1-d arrays, r_ and c_ are supposed to be exactly the same. It's only when you give them two dimensional arrays that they differ. Admittedly, I really like the one-dimensional array creation ability of r_ and I use it quite often. The two-dimensional array creation is not as good. bmat is intended to improve that some. I am open to any ideas about how to improve this. Perhaps, we just kill c_ and suggest something else (like an improved bmat) for building 2-d arrays quickly.
But, your transpose question is resolved by recognizing that there is a difference between a rank-1 array and a rank-2 matrix (which can be a column or row). Perhaps we should have a mechanism (perhaps a row_[...]) that generates a rank-2 row vector very quickly.
Ideas are welcome,
-Travis
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
A Divendres 22 Octubre 2004 01:53, Gerald Richter va escriure:
shouldn't c_[...] result in something like array([ [ . ], [ . ] ]) while r_ results in array([ ... ]) ?
why does:
In [23]: a = r_[1:3:5j]
In [24]: b = c_[2:6:5j]
In SciPy tutorial (http://www.scipy.org/documentation/tutorial.pdf) Travis Oliphant says: """ The "r" stands for row concatenation because if the ob jects between commas are 2 dimensional arrays, they are stacked by rows (and thus must have commensurate columns). There is an equivalent command c that stacks 2d arrays by columns but works identically to r for 1d arrays. """ So, it seems that this is not a bug, but a feature. Although I would also find interesting that r_[1:3:5j] would generate: array([ 1. , 1.5, 2. , 2.5, 3. ]) and that c_[1:3:5j]) would do: array([[ 1. ], [ 1.5], [ 2. ], [ 2.5], [ 3. ]]) However, I don't know if this would be counter-intuitive in some cases. -- Francesc Alted
I understood, just after I sent my first email, that the dimensions of the array are different for the suggested behaviour, since: shape(r_[1:3:5j]) (5,) while for a corresponding row-vector ( 1 by N matrix) it had to be something like: array([ r_[1:3:5j] ]) [ [ 1. 1.5 2. 2.5 3. ]] with: shape(array([ r_[1:3:5j] ])) (1, 5) And the column vectors had to be of shape (5, 1) which is achieved by: transpose(array([c_[1:3:5j]])) or transpose(array([r_[1:3:5j]])) - I found this confusing... So the current behaviour of c_ and r_ IMHO looks like a re-write of vstack and hstack together with linspace functionality, which doesn't supply any distinct functionality, or clearer usability of matrix notations or operations. When I first read the introduction to scipy I was hoping for ease-of-use abbreviations for matrix operations, and at first understood the shortcuts r_ and c_ to help with that. OK. -I was wrong ;) btw.: is it an issue at all, to discuss something like this here? -This is implemented at quite a low level, and I'm not sure if there is a way to retain backwards-compatibility, AND provide another behaviour of c_ and r_. On Fri, Oct 22, 2004 at 02:19:19PM +0200, Francesc Alted wrote:
In SciPy tutorial (http://www.scipy.org/documentation/tutorial.pdf) Travis Oliphant says:
"""
The "r" stands for row concatenation because if the ob jects between commas are 2 dimensional arrays, they are stacked by rows (and thus must have commensurate columns). There is an equivalent command c that stacks 2d arrays by columns but works identically to r for 1d arrays.
"""
So, it seems that this is not a bug, but a feature. Although I would also find interesting that r_[1:3:5j] would generate:
array([ 1. , 1.5, 2. , 2.5, 3. ])
and that c_[1:3:5j]) would do:
array([[ 1. ], [ 1.5], [ 2. ], [ 2.5], [ 3. ]])
However, I don't know if this would be counter-intuitive in some cases.
-- Francesc Alted
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
-- Gerald Richter <richter@hephy.oeaw.ac.at> phone: +43 1 5447328/27 Institute of high energy physics (HEPHY) http://wwwhephy.oeaw.ac.at/ Vienna/Austria
On Fri, 22 Oct 2004, Gerald Richter apparently wrote:
So the current behaviour of c_ and r_ IMHO looks like a re-write of vstack and hstack together with linspace functionality, which doesn't supply any distinct functionality, or clearer usability of matrix notations or operations. When I first read the introduction to scipy I was hoping for ease-of-use abbreviations for matrix operations, and at first understood the shortcuts r_ and c_ to help with that.
Perhaps you are looking for 'bmat', which unfortunately is not covered in the tutorial. hth, Alan Isaac
On Fri, 22 Oct 2004, Francesc Alted apparently wrote:
So, it seems that this is not a bug, but a feature. Although I would also find interesting that r_[1:3:5j] would generate: array([ 1. , 1.5, 2. , 2.5, 3. ]) and that c_[1:3:5j]) would do: array([[ 1. ], [ 1.5], [ 2. ], [ 2.5], [ 3. ]]) However, I don't know if this would be counter-intuitive in some cases.
I think that would be backwards of what is expected, since r_[] is supposed to create a stack of rows. But perhaps the following from http://www.american.edu/econ/pytrix/pyGAUSS.py gives you what you want. (Requires access to arange and transpose from Scipy, Numeric, or numarray.) Cheers, Alan Isaac #seqa: n element additive sequence from start by inc def seqa(start,inc,n): return transpose([start+inc*arange(n)])
participants (5)
-
Alan G Isaac -
Francesc Alted -
Gerald Richter -
Robert Kern -
Travis Oliphant