Incompatible with arrays

[tony-aw]

Hi Grant!

I very much enjoyed using 'tinyplot', so thanks for creating it!
But there are a few small things I've noticed.

Entering arrays works for base plot, but produces an error for tinyplot:

> x <- 1:10
> y <- array(1:10, c(1, 10))
> plot(x, y)
> tinyplot::tinyplot(x, y)
Error in .axisPars(usr, log = log, nintLog = nint) : 
  non-finite axis extents [GEPretty(-inf,inf, n=5)]
In addition: Warning messages:
1: In min(x, na.rm = na.rm) :
  no non-missing arguments to min; returning Inf
2: In max(x, na.rm = na.rm) :
  no non-missing arguments to max; returning -Inf

Making those 2 arrays a 'broadcaster' (a simple class from the 'broadcast' package) still works for base plot, but produces a different error for tinyplot:

> broadcaster(x) <- broadcaster(y) <- TRUE
> plot(x, y)
> tinyplot::tinyplot(x, y)
Error in `[.default`(xj, i, , drop = FALSE) : subscript out of bounds

Is tinyplot incompatible with arrays? If so, perhaps this can be made more clear in the error message.

Kind regards,

Tony

[grantmcdermott]

Thanks for the kind words @tony-aw.

The truth is that we don't (currently) do a great job of supporting tinyplot.* methods for non-vector arrays. For example, we don't have a tinyplot.matrix method and even our data.frame support is contingent on providing an explicit formula. See here for some related discussion: #347

In this particular case, I'm not sure if these "primitive" base R arrays are a prerequisite for broadcast support. But perhaps the easiest solution is to define tinyplot.broadcast method in your own package, which converts the objects to appropriate vectors or data.frames?

[grantmcdermott]

To clarify: I'm happy to consider a PR for tinyplot.array here. But I'll be honest that we might not be able to review it for a week or three. So, I'm just thinking about the path of least resistance to unblock you quickly.

[zeileis]

I also thought that a tinyplot.broadcast methods might be a good idea. However, for me the example based on the broadcast package works ok, both with the CRAN and the devel version of tinyplot. So maybe this isn't even necessary?

Regarding a general array method: I'm not sure whether this would solve the problem here. First, x is a plain vector and thus the array method wouldn't even be called. Second, if one would dispatch to a suitable method one would probably expect that the number of rows in y matches the number of elements in x (as matplot(x, y) would do).

Looking at why plot(x, y) works it turns out that xy.coords() is called internally by plot.default(). This coerces to as.double(x) and as.double(y) which we cannot do in tinyplot.default() because we need to preserve the classes as the type functions need them.

Hence I think the only thing we can do is have a closer look at sanitize_datapoints() which is the root of the problem here. Implicitly, this expects that all the data arguments (x, y, xmin, xmax, ...) can be turned into a data frame with the same number of rows. In this example, this would only be possible if we drop(y) the dimension of y, e.g., via something like:

if (!is.null(dim(x))) x <- drop(x)
if (!is.null(dim(y))) y <- drop(y)

But I'm not sure whether this is a good idea in general. Alternatively, we could check the number of rows and columns after creating the first datapoints list (https://github.com/grantmcdermott/tinyplot/blob/main/R/sanitize_datapoints.R#L41-L44). Here, this would yield:

vapply(datapoints, NROW, 0L)
     x   xmin   xmax      y   ymin   ymax ygroup 
    10      0      0      1      0      0      0 
vapply(datapoints, NCOL, 0L)
     x   xmin   xmax      y   ymin   ymax ygroup 
     1      0      0     10      0      0      0 

And then we could trigger a warning if non-scalar elements have a mismatch in the number of rows.

[tony-aw]

For vectors/arrays with the 'broadcaster' class, you may just go the base 'R' route and call as.double() on them after they've passed method dispatch. Or am I thinking too simplistic here?

[zeileis]

Maybe I misunderstand your comment. But tinyplot() should not have any dedicated code for the broadcaster class - and it shouldn't generally coerce all arrays via as.double(). Hence, my idea above was to coerce (or just drop the dimension) in those cases only where the dimensions match.

[tony-aw]

Ah, ok, my bad.
Anyways, this issue was primarily just to point this behaviour Ive noticed. And I gave the suggestion to return a more informative error message for arrays. Thats it.

[zeileis]

Sure, it's a very good point and much appreciated!

The question is just which cases we want sanitize_datapoints() to warn about and which cases it should coerce without warning. Tagging both Grant @grantmcdermott and Vincent @vincentarelbundock for their feedback. Consider these setups:

library("tinyplot")
y <- matrix(11:19, ncol = 3)
s0 <- new.env()
s0$null_by <- TRUE
s0$x <- 1:3

And then we can play with various arrays for y :

s <- s0
s$y <- y[, 1, drop = FALSE] ## 1-column matrix (correct nrows)
tinyplot:::sanitize_datapoints(s)
s$datapoints ## ok
##   x  y rowid facet by
## 1 1 11     1         
## 2 2 12     2         
## 3 3 13     3         
s$datapoints$y ## dimension dropped
## [1] 11 12 13

 s <- s0
s$y <- y ## multi-column matrix (correct nrows)
tinyplot:::sanitize_datapoints(s)
s$datapoints ## y coerced to separate variables
##   x y.1 y.2 y.3 rowid facet by
## 1 1  11  14  17     1         
## 2 2  12  15  18     2         
## 3 3  13  16  19     3         
s$datapoints$y ## no y
## NULL

s <- s0
s$y <- y[1, , drop = FALSE] ## 1-row matrix (ncols matches nrows)
tinyplot:::sanitize_datapoints(s)
s$datapoints ## y gets replicated and coerced to separate columns
##   x y.1 y.2 y.3 rowid facet by
## 1 1  11  14  17     1         
## 2 2  11  14  17     2         
## 3 3  11  14  17     3         

Questions:

• 1-column matrix: Should the dimension be dropped?
• Multi-column matrix: Should probably be a single matrix variable y?
• 1-row matrix: Should the dimension be dropped and handled like the 1-column matrix?

Note that what feels "intuitive" might differ between plot types.

[grantmcdermott]

Thanks both for the thoughtful discussion and working through the options.

Quick, off-the-cuff replies to your questions, @zeileis :

• 1-column matrix: Should the dimension be dropped?

That would be my instinct. Offhand, I can't think a reason why we'd want to keep the dimensions here...

• Multi-column matrix: Should probably be a single matrix variable y?

Yes, but grouped (alongside the reshaping to long)? I think the default output should be analogous to matplot.

• 1-row matrix: Should the dimension be dropped and handled like the 1-column matrix?

Yes, I think so.

[zeileis]

For the arrays where the dimension can simply be dropped I'm also inclined to do so. I can't think of any cases where the dimension would need to be preserved.

For scatterplots and lineplots it is indeed very natural to handle a matrix y like grouped data. And it would be very nice to have a straightforward tinyplot alternative to matplot with better defaults.

However, for categorical data, it would also be natural to plot contingency tables directly, e.g., via type_barplot or type_spineplot. In the base R spineplot function you can do this whereas in tinyplot::type_spineplot you need to turn the contingency table into a long data frame:

spineplot(HairEyeColor[,,1])
tinyplot(Eye ~ Hair, data = hec, type = type_spineplot(weights = hec$Freq))

Hence, I'm not sure how we would generally process such data in sanitize_datapoints...

[tony-aw]

This made me wonder: how does ggplot2 deal with the method dispatch issue? I know usually the input for ggplot must be a data.frame, but there's also ggplot support for things like polygons. Maybe some of ggplot's dispatch logic can be used as inspiration for tinyplot? Or is that simply not applicable for tinyplot?