On Wed, Feb 2, 2011 at 02:16, Paul Murrell <p.murr...@auckland.ac.nz> wrote: > Hi > > On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote: >> >> On Tue, Feb 1, 2011 at 4:46 PM, Paul Murrell<p.murr...@auckland.ac.nz> >> wrote: >>> >>> Hi >>> >>> On 1/02/2011 9:22 p.m., Martin Maechler wrote: >>>>>>>>> >>>>>>>>> Henrik Bengtsson<h...@biostat.ucsf.edu> >>>>>>>>> on Mon, 31 Jan 2011 11:16:59 -0800 writes: >>>> >>>> > Hi, str() on raster objects fails for certain dimensions. For >>>> > example: >>>> >>>> >> str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100] >>>> > "#000000" "#000000" "#000000" "#000000" ... >>>> >>>> >> str(as.raster(0, nrow=1, ncol=101)) Error in >>>> `[.raster`(object, >>>> > seq_len(max.len)) : subscript out of bounds >>>> >>>> > This seems to do with how str() and "[.raster"() is coded; when >>>> > subsetting as a vector, which str() relies on, "[.raster"() >>>> > still returns a matrix-like object, e.g. >>>> >>>> >> img<- as.raster(1:25, max=25, nrow=5, ncol=5); >>>> >> img[1:2] >>>> > [,1] [,2] [,3] [,4] [,5] >>>> > [1,] "#0A0A0A" "#3D3D3D" "#707070" "#A3A3A3" "#D6D6D6" >>>> > [2,] "#141414" "#474747" "#7A7A7A" "#ADADAD" "#E0E0E0" >>>> >>>> > compare with: >>>> >>>> >> as.matrix(img)[1:2] >>>> > [1] "#0A0A0A" "#3D3D3D" >>>> >>>> >>>> > The easy but incomplete fix is to do: >>>> >>>> > str.raster<- function(object, ...) { >>>> > str(as.matrix(object), ...); >>>> > } >>>> >>>> > Other suggestions? >>>> >>>> The informal "raster" class is behaving ``illogical'' >>>> in the following sense: >>>> >>>> > r<- as.raster(0, nrow=1, ncol=11) >>>> > r[seq_along(r)] >>>> Error in `[.raster`(r, seq_along(r)) : subscript out of bounds >>>> >>>> or, here equivalently, >>>> > r[1:length(r)] >>>> Error in `[.raster`(r, 1:length(r)) : subscript out of bounds >>>> >>>> When classes do behave in such a way, they definitely need their >>>> own str() method. >>>> >>>> However, the bug really is in "[.raster": >>>> Currently, r[i] is equivalent to r[i,] which is not at all >>>> matrix-like and its help clearly says that subsetting should >>>> work as for matrices. >>>> A recent thread on R-help/R-devel has mentioned the fact that >>>> "[" methods for matrix-like methods need to use both nargs() and >>>> missing() and that "[.dataframe" has been the example to follow >>>> "forever", IIRC already in S and S-plus as of 20 years ago. >>> >>> The main motivation for non-standard behaviour here is to make sure that >>> a >>> subset of a raster object NEVER produces a vector (because the conversion >>> back to a raster object then produces a single-column raster and that may >>> be >>> a "surprise"). Thanks for making the code more standard and robust. >>> >>> The r[i] case is still tricky. The following behaviour is quite >>> convenient >>> ... >>> >>> r[r == "black"]<- "white" >>> >>> ... but the next behaviour is quite jarring (at least in terms of the >>> raster >>> image that results from it) ... >>> >>> r2<- r[1:(nrow(r) + 1)] >>> >>> So I think there is some justification for further non-standardness to >>> try >>> to ensure that the subset of a raster image always produces a sensible >>> image. A simple solution would be just to outlaw r[i] for raster objects >>> and force the user to write r[i, ] or r[, j], depending on what they >>> want. >> >> FYI, I've tried out Martin's updated version at it seems like a >> one-column raster matrix is now returned for r[i], e.g. > > Yes, that's what I've been looking at ... > >>> r<- as.raster(1:8, max=8, nrow=2, ncol=4); >>> r >> >> [,1] [,2] [,3] [,4] >> [1,] "#202020" "#606060" "#9F9F9F" "#DFDFDF" >> [2,] "#404040" "#808080" "#BFBFBF" "#FFFFFF" >> >>> r[1:length(r)] >> >> [,1] >> [1,] "#202020" >> [2,] "#404040" >> [3,] "#606060" >> [4,] "#808080" >> [5,] "#9F9F9F" >> [6,] "#BFBFBF" >> [7,] "#DFDFDF" >> [8,] "#FFFFFF" > > ... and the above is exactly the sort of thing that will fry your mind if > the image that you are subsetting is, for example, a photo. > > Paul
I agree. But the r[i] case (not subassignment, but subsetting) case has been in the code, and that's why I left it .. but changed it to behave sensibly in the sense of "compatible" to matrix.... ... and with the consequence that r[1:length(r)] does not give an error ... and in this sense behaves more regular. Yet another alternative might be to only raise a warning and perhaps return a (character) vector as that is very compatible to matrix behavior. BTW, you haven't mentioned the r[xy] indexing where xy is a two-column matrix of indices. There it's even more non-sense to return > >>> r[1:5,drop=TRUE] >> >> [,1] >> [1,] "#202020" >> [2,] "#404040" >> [3,] "#606060" >> [4,] "#808080" >> [5,] "#9F9F9F" >> Warning message: >> In `[.raster`(r, 1:5, drop = TRUE) : >> 'drop' is always implicitly FALSE in '[.raster' >> >> Also, >> >>> r[1:5]<- "white" >>> r >> >> [,1] [,2] [,3] [,4] >> [1,] "white" "white" "white" "#DFDFDF" >> [2,] "white" "white" "#BFBFBF" "#FFFFFF" >> >> /Henrik >> >>> >>> Paul >>> >>>> Thank you, Henrik, for the bug report. >>>> Martin >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> -- >>> Dr Paul Murrell >>> Department of Statistics >>> The University of Auckland >>> Private Bag 92019 >>> Auckland >>> New Zealand >>> 64 9 3737599 x85392 >>> p...@stat.auckland.ac.nz >>> http://www.stat.auckland.ac.nz/~paul/ >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> > > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > p...@stat.auckland.ac.nz > http://www.stat.auckland.ac.nz/~paul/ > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel