Whether something "is" a matrix depends on whether you listen to is.matrix(x) or to inherits(x, "matrix"):
x = Sys.Date () + 1:16 y = as.POSIXct (x) dim(y) = c(4,4) is.matrix(y) # [1] TRUE inherits(y, "matrix") # [1] FALSE f = factor(letters[1:9]) dim(f) = c(3,3) is.matrix(f) # [1] TRUE inherits(f, "matrix") # [1] FALSE I'm using (abusing?) this in the stars package, where it is convenient to have n-D arrays of type factor, Date or POSIXct, mostly because the [ method works: (f2 <- f[1:2,1:2]) # [,1] [,2] # [1,] a d # [2,] b e # Levels: a b c d e f g h i is.matrix(f2) # [1] TRUE On 1/28/20 9:09 AM, Abby Spurdle wrote: >>> Maybe I'm missing something really obvious here, but I was unable to >>> create a matrix out of POSIXct object(s). >>> Perhaps that deserves a separate discussion...? >> Can you provide an example? > > ------ > #date and time objects > x = Sys.Date () + 1:16 > y = as.POSIXct (x) > > #matrices > str (matrix (x, 4, 4) ) > str (matrix (y, 4, 4) ) > ------ > > Creating a matrix from a Date or POSIXct object, results in a numeric > matrix, not a date/time matrix. > > I think that date/time matrices could be useful. > It's possible that this has been discussed before. > But if not, it may be good to discuss it. > > And returning to your original post... > > I re-read the documentation for the matplot function. > And I feel that it's ambiguous. > > The description says: > "Plot the columns of one matrix against the columns of another." > i.e. The matplot function is for *matrices*. > > However, then it says: > "x,y vectors or matrices of data for plotting. The number of rows should > match." > > I'm guessing the current intention is that standard vectors (without a > dim attribute) would be coerce-ible to single-column matrices, > implying that using this function with date and time objects, is > contrary to the way it's currently designed to work. > > But... > > After reading your examples and re-reading the documentation, your > main suggestion that matplot should support Date and POSIXct objects, > is still *probably* a good one. I note that function is not generic, > and modifications to it would not necessarily be trivial. > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48151 Muenster, Germany Phone: +49 251 8333081 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel