[Numpy-discussion] r_, c_, hstack, and vstack with 1-d arrays
wbaxter at gmail.com
Fri Jul 21 07:22:18 CDT 2006
On 7/21/06, Sven Schreiber <svetosch at gmx.net> wrote:
> Bill Baxter schrieb:
> > Finally, I noticed that the atleast_nd methods return arrays
> > regardless of input type.
> Are you sure? I reported that issue with *stack and I remember it was fixed.
Doh! My bad. You're right. I was looking at the code in SVN for the
and didn't realize that the array constructor (or any constructor)
could actually return something besides an object of that class. But
that's exactly what array(subok=True) allows.
> > SUMMARY:
> > * make r_ behave like "vstack plus range literals"
> > * make column_stack only transpose its 1d inputs.
> > * rename r_,c_ to v_,h_ (or something else) to make their connection
> > with vstack and hstack clearer. Maybe vs_ and hs_ would be better?
> > * make a new vertsion of 'c_' that acts like column_stack so that
> > theres a nice parallel v_<=>vstack, h_<=>hstack, c_<=>column_stack
> > * make atleast_*d methods preserve the input type whenever possible
> One problem with all that renaming is the other (maybe more important)
> function of r_: build (array or) matrix ranges quickly.
How would you duplicate this kind of behavior, you mean?
array([1, 2, 3, 0, 4])
That's what h_ would do. Just as if you had done hstack( (range(1,4),0,4) ).
That's actually a good reason for the renaming/retooling. r_ is kind
of schitzophrenic now in that it acts *either* as "concatenate rows
(vstack-like, for >=2-d)" or "build me a row (hstack-like, for <2d)".
So it's hard to remember what the 'r' in r_ stands for. On the other
hand, c_ is always hstack-like.
By the way, I noticed that 'row_stack' has appeared as a synonym for
'vstack' in SVN. Thanks to whomever added it!
More information about the Numpy-discussion