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

[Bill Baxter]

On 7/21/06, Sven Schreiber <[EMAIL PROTECTED]> 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
atleast_* methods
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?
>>>   r_[1:4,0,4]
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!

--bb

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Sven Schreiber]

Bill Baxter schrieb:

> Finally, I noticed that the atleast_nd methods return arrays
> regardless of input type.  At a minimum, atleast_1d and atleast_2d on
> matrices should return matrices.  I'm not sure about atleast_3d, since
> matrices can't be 3d.  (But my opinon is that the matrix type should
> be allowed to be 3d).  Anyway, since these methods are used by the
> *stack methods, those also do not currently preserve the matrix type
> (in SVN numpy).
> 

Are you sure? I reported that issue with *stack and I remember it was fixed.


> 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. So I'm a bit
against the renaming I guess. Cleaning up the irritations with the
*stacks seems useful though. (Although I have to confess I haven't read
your last mail very thoroughly.)
-Sven


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Bill Baxter]

I looked into the various concatenation methods a bit more to better
understand what's going on under the hood.

Here's essentially what these different methods do:

vstack(tup):
concatenate( map(atleast_2d,tup), axis=0 )

hstack(tup):
concatenate( map(atleast_1d,tup),axis=1 )

column_stack(tup):
arrays = map( transpose,map(atleast_2d,tup) )
concatenate(arrays,1)

(note that column_stack transposes *everything* not just 1-d inputs,
so it doesn't do quite what I thought it did, i.e. only transposing
1-d inputs)

The above 3 are pretty much exactly the code used by numpy.  That's
all there is to those 3 functions.
For r_ and c_ I'm summarizing, but effectively they seem to be doing
something like:

r_[args]:
concatenate( map(atleast_1d,args),axis=0 )

c_[args]:
concatenate( map(atleast_1d,args),axis=1 )

c_ behaves almost exactly like hstack -- with the addition of range
literals being allowed.

r_ is most like vstack, but a little different since it effectively
uses atleast_1d, instead of atleast_2d.  So you have
>>> numpy.vstack((1,2,3,4))
array([[1],
   [2],
   [3],
   [4]])
but
>>> numpy.r_[1,2,3,4]
array([1, 2, 3, 4])

However for cases like that with just 0-d or 1-d inputs, c_ behaves
identically to r_, so if you wanted to get a 1-d output you could have
just used c_.

So I take back what I said about wishing c_ were like column_stack.
Column stack is weird.
Instead, I think the right thing to do would be to make r_ behave more
like vstack.  I think that would make things more consistent, and make
for less for the user to remember.

After making that change, to make things even more consistent, it
might make sense to rename r_ and c_  to v_ and h_ instead.  Then it's
easy to remember  'v_' is like 'vstack',  'h_' is like hstack.

Furthermore, I propose that column_stack should only transpose its 1d
inputs.  "Stack colums" defnitely doesn't imply to me that something
that already has columns will be transposed.  Currently it is
documented to only work on 1d inputs, so hopefully that's a change
that wouldn't affect too many people.  The function in
numpy/lib/shape_base.py could be replaced with this:

def column_stack(tup):
def transpose_1d(array):
 if array.ndim<2: return _nx.transpose(atleast_2d(array))
 else: return array
arrays = map(transpose_1d,map(atleast_1d,tup))
return _nx.concatenate(arrays,1)

If r_, and c_ get renamed to v_, h_, then c_ could be re-introduced
with behavior similar to column_stack.

Finally, I noticed that the atleast_nd methods return arrays
regardless of input type.  At a minimum, atleast_1d and atleast_2d on
matrices should return matrices.  I'm not sure about atleast_3d, since
matrices can't be 3d.  (But my opinon is that the matrix type should
be allowed to be 3d).  Anyway, since these methods are used by the
*stack methods, those also do not currently preserve the matrix type
(in SVN numpy).

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

Thoughts?
--bb

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Bill Baxter]

On 7/19/06, Sven Schreiber <[EMAIL PROTECTED]> 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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Sven Schreiber]

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 ;-)
Seriously, I think all the quirks you mentioned recently are now gone.

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.

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!?

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).


> 
> 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).

Good luck,
Sven

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

[Bill Baxter]

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.

Background:
I keep getting bitten by the fact that this doesn't work:

>>> a = array([1,2,3])
>>> b = array([[1,2,3],[2,3,4]])
>>> c = array([4,5,6])
>>> r_[b,c]
**error**

and that this doesn't return a 2x3
>>> d = r_[a,c]
array([1, 2, 3, 4, 5, 6])

To get what I want I need something like :
>>> r_[[a],[c]]
array([[1, 2, 3],
   [4, 5, 6]])
And to get them columnwise I need the likes of:
>>> c_[a[:,newaxis], c[:,newaxis]]
array([[1, 4],
 [2, 5],
 [3, 6]])

It seems like the r_ (which I think of as a "row concatenator") should
assume that 1-d arrays are rows (like vstack does), and the c_
("column concatenator") should assume 1-d arrays are columns (like
column_stack does).

Then you'd have:
>>> r_[a,c]
array([[1, 2, 3],
 [4, 5, 6]])
>>> c_[a,c]
array([[1, 4],
 [2, 5],
 [3, 6]])

At any rate, r_'s behavior is currently different from vstack wrt 1-d
arrays, and identitcal to c_ and hstack.

Vstack, hstack, and column_stack give the following:
>>> vstack([a,c])
array([[1, 2, 3],
 [4, 5, 6]])
>>> hstack([a,c])
array([1, 2, 3, 4, 5, 6])
>>> column_stack([a,c])
array([[1, 4],
 [2, 5],
 [3, 6]])

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.

--bb

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion