# [Rd] nrow(rbind(character(), character())) returns 2 (as documented but very unintuitive, IMHO)

robin hankin h@nk|n@rob|n @end|ng |rom gm@||@com
Thu May 16 23:25:14 CEST 2019

```Gabriel, you ask an insightful and instructive question. One of R's
great strengths is that we have a forum where this kind of edge-case
can be fruitfully discussed.
My interest in this would be the names of the arguments; in the magic
package I make heavy use of the dimnames of zero-extent arrays.

> rbind(a='x',b='y')
[,1]
a "x"
b "y"

> rbind(a='x',b=character())
[,1]
a "x"

> rbind(a=character(),b=character())

a
b

The first and third idiom are fine.  The result of the second one, in
which we rbind() a length-one to  a length-zero vector, is desirable
IMO on the grounds that the content of a two-row matrix cannot be
defined sensibly, so R takes the perfectly reasonable stance of
deciding to ignore the second argument...which carries with it the
implication that the name ('b')  be ignored too.  If the second
argument *could* be recycled, I would want the name, otherwise I
wouldn't.  And this is what R does.

best wishes,

hankin.robin using gmail.com

hankin.robin using gmail.com

On Fri, May 17, 2019 at 9:06 AM Hadley Wickham <h.wickham using gmail.com> wrote:
>
> The existing behaviour seems inutitive to me. I would consider these
> invariants for n vector x_i's each with size m:
>
> * nrow(rbind(x_1, x_2, ..., x_n)) equals n
> * ncol(rbind(x_1, x_2, ..., x_n)) equals m
>
> Additionally, wouldn't you expect rbind(x_1[i], x_2[i]) to equal
> rbind(x_1, x_2)[, i, drop = FALSE] ?
>
>
> On Thu, May 16, 2019 at 3:26 PM Gabriel Becker <gabembecker using gmail.com> wrote:
> >
> > Hi all,
> >
> > Apologies if this has been asked before (a quick google didn't  find it for
> > me),and I know this is a case of behaving as documented but its so
> > unintuitive (to me at least) that I figured I'd bring it up here anyway. I
> > figure its probably going to not be changed,  but I'm happy to submit a
> > patch if this is something R-core feels can/should change.
> >
> > So I recently got bitten by the fact that
> >
> > > nrow(rbind(character(), character()))
> >
> > [1] 2
> >
> >
> > I was checking whether the result of an rbind call had more than one row,
> > and that unexpected returned true, causing all sorts of shenanigans
> > downstream as I'm sure you can imagine.
> >
> > Now I know that from ?rbind
> >
> > For ‘cbind’ (‘rbind’), vectors of zero length (including ‘NULL’)
> > >
> > >      are ignored unless the result would have zero rows (columns), for
> > >
> > >      S compatibility.  (Zero-extent matrices do not occur in S3 and are
> > >
> > >      not ignored in R.)
> > >
> >
> > But there's a couple of things here. First, for the rowbind  case this
> > reads as "if there would be zero columns,  the vectors will not be
> > ignored". This wording implies to me that not ignoring the vectors is a
> > remedy to the "problem" of the potential for a zero-column return, but
> > thats not the case.  The result still has 0 columns, it just does not also
> > have zero rows. So even if the behavior is not changed, perhaps this
> > wording can be massaged for clarity?
> >
> > The other issue, which I admit is likely a problem with my intuition, but
> > which I don't think I'm alone in having, is that even if I can't have a 0x0
> > matrix (which is what I'd prefer) I would have expected/preferred a 1x0
> > matrix, the reasoning being that if we must avoid a 0x0 return value, we
> > would do the  minimum required to avoid, which is to not ignore the first
> > length 0 vector, to ensure a non-zero-extent matrix, but then ignore the
> > remaining ones as they contain information for 0 new rows.
> >
> > Of course I can program around this now that I know the behavior, but
> > again, its so unintuitive (even for someone with a fairly well developed
> > intuition for R's sometimes "quirky" behavior) that I figured I'd bring it
> > up.
> >
> > Thoughts?
> >
> > Best,
> > ~G
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --