Colour recycling without `by` variable

[zeileis]

In #410 we had improved the colour recycling when groups are defined using a by variable. This still seems to be fine to me.

When there is no by variable, i.e., only y and/or x, then only a single color is used because there is only a single by group. This makes sense in many situations but sometimes you want to color every point/line/bar with a different color (as in #476). This is possible in base R's plot() but in tinyplot() it requires setting up a suitable by variable.

As a simple example, consider plotting points 1:5 in colors 1:5:

    plot(1:5, col = 1:5, pch = 19, cex = 5)
tinyplot(1:5, col = 1:5, pch = 19, cex = 5)
tinyplot(1:5, col = 1:5, pch = 19, cex = 5, by = factor(1:5), legend = FALSE)

• In base R just setting col = 1:5 is sufficient for getting five points in five different colors.
• In tinyplot this is identified as a scenaria with only a single by group and hence only one color is used.
• This can only be changed easily with a categorical by variable.

Maybe in the case without by variable we need to reconsider the color recycling rules?

[grantmcdermott]

Agree that this would be nice, but two quick caveats:

1. Checking for unique values of x is a potentially expensive operation for large datasets. Can we avoid doing that every time with smart if-else logic?
2. Recycling for points and bar plots makes sense. But how would this work for, say, line plots. I don't have a good intuition for what this would (should) look like... And don't know if the our current internal plotting logic could even support it.

[zeileis]

Both very good points! Maybe the following would work:

• If there is no by variable
• and graphical elements like col, fill, lty, pch, cex, etc. are of the same length as the number of observations
• then we pass them through rather than reducing them to length 1 and
• the type_draw then has to decide what to do with it

This would mean, though, that we have to go through all type_*() functions and reduce icol, ilty, to length 1 in these scenarios. Note sure that this is worth the effort.

Otherwise we would need to introduce a flag that the type_*() can set to declare whether it is capable of this or not, the default being FALSE. Then we would only need to adapt those types that can deal with this situation.

Another catch is the situation with facets. Then the logic above would correspond to the number of observations per facet. And if that is always the same, it should be clear enough what to do, provided the x values always come in the same order. But what to do if the number of observations differ and or their order differs is not obvious to me.

All in all, I'm not sure that this convenience is worth the special casing we would have to do. If we think we want to do it, we should wait until #473 is done. And if we don't do it, then maybe a short vignette on the topic of idiomatic by variable usage might be helpful.