![](https://secure.gravatar.com/avatar/915f9e3213021d75d43bb4262167b067.jpg?s=120&d=mm&r=g)
When you have a chance, could the powers that be make some comment on the r_ and c_ situation? From what I understand Travis added these fairly recently and they aren't officially documented anywhere. There was discussion previously about whether to rename them or not, but no real conclusion was reached on better names (I've kind of grown to like the x_ style naming in the mean time). I do think the subtle differences in behavior between these and existing methods (hstack,vstack,column_stack) are an issue, though, which I outlined in a previous email. Thanks, --Bill
![](https://secure.gravatar.com/avatar/747dbe713fc00913cb5e798754feae7f.jpg?s=120&d=mm&r=g)
On Monday 31 July 2006 16:29, Bill Baxter wrote: [BB]: the r_ and c_ situation? From what I understand Travis added these [BB]: fairly recently and they aren't officially documented anywhere. I know r_ is fully documented in the (fee-based) reference manual of Travis. In addition, I've taken care of many examples of this function in the Numpy Example List. But perhaps I'm misunderstanding your comment... Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Bill Baxter wrote:
For NumPy, c_ has been deprecated (but not removed because it is used in SciPy). The functionality of c_ is in r_ so it doesn't add anything. The purpose of it is as a "convenience function" so you can build arrays from the command line very quickly (which is easier in MATLAB). They were added while I was teaching a course in Signal Processing and was porting some MATLAB-written labs to SciPy. There is going to be overlap with long-name functions because of this. I have not had time to review Bill's suggestions yet --- were they filed as a ticket? A ticket is the best way to keep track of issues at this point. -Travis
![](https://secure.gravatar.com/avatar/915f9e3213021d75d43bb4262167b067.jpg?s=120&d=mm&r=g)
On 8/1/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
I don't see how r_ offers the ability to stack columns like this:
I just filed it as #235. But then I noticed I had already filed it previously as #201. Sorry about that. Anyway it's definitely in there now. Regards, --Bill
![](https://secure.gravatar.com/avatar/747dbe713fc00913cb5e798754feae7f.jpg?s=120&d=mm&r=g)
On Monday 31 July 2006 16:29, Bill Baxter wrote: [BB]: the r_ and c_ situation? From what I understand Travis added these [BB]: fairly recently and they aren't officially documented anywhere. I know r_ is fully documented in the (fee-based) reference manual of Travis. In addition, I've taken care of many examples of this function in the Numpy Example List. But perhaps I'm misunderstanding your comment... Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Bill Baxter wrote:
For NumPy, c_ has been deprecated (but not removed because it is used in SciPy). The functionality of c_ is in r_ so it doesn't add anything. The purpose of it is as a "convenience function" so you can build arrays from the command line very quickly (which is easier in MATLAB). They were added while I was teaching a course in Signal Processing and was porting some MATLAB-written labs to SciPy. There is going to be overlap with long-name functions because of this. I have not had time to review Bill's suggestions yet --- were they filed as a ticket? A ticket is the best way to keep track of issues at this point. -Travis
![](https://secure.gravatar.com/avatar/915f9e3213021d75d43bb4262167b067.jpg?s=120&d=mm&r=g)
On 8/1/06, Travis Oliphant <oliphant.travis@ieee.org> wrote:
I don't see how r_ offers the ability to stack columns like this:
I just filed it as #235. But then I noticed I had already filed it previously as #201. Sorry about that. Anyway it's definitely in there now. Regards, --Bill
participants (3)
-
Bill Baxter
-
Joris De Ridder
-
Travis Oliphant