add_column() with zero-row data frame

[krlmlr]

The following still doesn't work as expected:

add_column(iris[0, ], a = character(), b = 1)
## Error: Variables must be length 1 or 1.
## Problem variables: 'a'

I'd expect the result to be a zero-row data frame with two new columns a (character) and b (numeric).

I suspect we need a special case for zero-row input. @LaDilettante: Would you mind taking a look?

[anhqle]

Yes, I'd be happy to.

iris[0, ] and a are empty, but b has data. Shouldn't adding data to zero-row data frame throw an error instead of silently giving back a zero-data frame? The user may think that the data in b is successfully added somehow.

I have the same question about issue #147

[anhqle]

@krlmlr I can take on this next, but please give some guidance on my point in the previous comment. I think

add_column(iris[0, ], a = character(), b = 1)

should give an error instead of a zero-row data frame. Otherwise, the user may think that the data from b = 1 successfully gets added.

[krlmlr]

How about a new argument .allow_atomic = NA? TRUE allows this use case, FALSE explicitly forbids adding atomic values (forcing to always use full vectors), and NA is the current behavior.

[anhqle]

Could you elaborate? My understanding is that add_column has always allowed adding atomic values (using recycle to fill the column with that atomic value).

The issue at hand is how should add_column behave when the user add a column to a zero-row data frame.

• Your top post suggests returning a zero-row data frame with new column
• I suggests raising an error to highlight that the data in the new column is not added

Is allow_atomic related to this choice? I'd appreciate more clarification. Thanks!

[krlmlr]

Support for atomic values is very recent (#164, thanks!), and not on CRAN yet, so there's time to reconsider.

This issue was motivated by the desire to provide a robust interface for programming that also works in the zero-row corner case. Maybe we just need a new add_column_atomic(), and throw an error as we did before with add_column?

[anhqle]

I see. IMO,

1. We should keep adding an atomic value as the default because users are probably accustomed to cbind(1:4, 1). Plus, adding a constant is a common task (e.g. adding an intercept, some categorical values, etc.)
2. Regarding zero-row tibble, I still can't imagine an use case for it, but my best guess is that it's used to initialize storage. With that assumption,
   • add_column(iris[0, ], a = character(), b = integer()) returns a zero-row tibble with new columns as expected
   • add_column(iris[0, ], a = character(), b = 1) should never happen. If it does, we should raise an error to alert the user with a better message rather than silently returning a zero-row tibble. Imagine being a reader of the code, seeing add_column(iris[0, ], a = character(), b = 1) raising no error. I would wrongly expect b = 1 to be added in the tibble.

So in sum, I suggest we keep the behavior of add_column and improve the error message in the case of zero-row edge case.

[krlmlr]

Zero-row tibbles can occur in a data analysis (think empty groups). I think this corner case needs to be handled well.

Thinking again, it's only about mixing length-one and length-n columns where the problem occurs. The real cause for this behavior is that tibble(a = 1:3, b = 1) succeeds but tibble(a = integer(), b = 1) raises an error; we might as well fix that.

Let's keep this issue open for a while and think of a clean way to handle this.

[anhqle]

IMO tibble(a = integer(), b = 1) raising an error makes sense. 1 is not divisible by 0. The user should not expect recycling-like behavior here.

[krlmlr]

I'm thinking more of a programming context: The integer() might be a vector of unknown length, in this case it's not very helpful to have to special-case for zero.