Re: [Numpy-discussion] r_, c_, hstack, and vstack with 1-d arrays

[Bill B. <wb...@gm...>]

On 7/19/06, Sven Schreiber <sve...@gm...> wrote:
> Bill Baxter schrieb:
> > For 1-d inputs I think r_ should act like vstack, and c_ should act
> > like column_stack.
> > Currently r_ and c_ both act like hstack for 1-d inputs.
>
> Well Bill, as I said before, you should have stayed with matrices ;-)

:-D

> Seriously, I think all the quirks you mentioned recently are now gone.

Yeh, probably so.  The main one remaining for me is that matrix can't
take more than 2-D data.  So if I decide to go, say, from storing a
single polygon (N points x 2 coords), to a set of deformed versions of
the polygon (M deformations x N points x 2 coords), then suddenly I
have to switch a bunch of matrix types back to array types, and find
and fix all the small differences between the two, and deal with two
different types in my code (array and matrix) instead of one type
everywhere (array).  Or maybe I have to use a Python list of matrix.

Maybe it wouldn't be as bad as I imagine.  I haven't actually gone
through such a conversion with matrices.  It just seems like it would
probably be more pain than it is to add an extra dimension without
changing data type.


> I mean what you're experiencing now ist just logical from the point of
> view that rows and columns are 2d concepts, so a 1d array just isn't enough.

True, but other parts of Numpy handle that ambiguity more gracefully.
Like dot(), or column_stack.


> Having said that, however, here are some more constructive comments:
>
> First, I think using c_ is not recommended, it doesn't even appear in
> the book. But I have no idea why that is so, I'm using it also (with
> matrices), so I think it's valid to question that deprecation. Indeed it
> seems natural to make it act like column_stack for 1d arrays!?

Hmm, yeh, what is the status on r_ and c_?   My understanding was that
they were just new/experimental, and thus not documented in the book.
 I think they're quite handy, so I hope they're not going away.  There
was a discussion previously about changing the names to something a
little more attractive, but I've gotten pretty used to the names now.

> Second, changing r_ would obviously break some people's codes. Two
> workarounds: You switch to matrices (sorry, couldn't resist), or you use
> vstack (trivial, sorry again).

Well, if they are new, probably not that much code.

> > Also isn't it odd that there's a column_stack, but no row_stack?  I
> > guess that's because row_stack would just be an alias for vstack, but
> > still.

> I agree that for the poor non-matrix-users it would be good to have a
> pair of names that obviously belong together, instead of the current
> vstack/column_stack situation; with matrices you have the choice of
> r_/c_ or vstack/hstack that do exactly what you want (as you know).

--bill