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.