[Rd] plotmath degree symbol
In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. -- 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
Re: [Rd] [FORGED] Re: plotmath degree symbol
Thanks, Paul -- setting the ~/.fonts.conf file the way ?X11 describes it under the section you pointed to resolved the problem for me, on ubuntu. On 09/04/2018 11:55 PM, Paul Murrell wrote: > Hi > > Thanks for that, but I still cannot confirm on ... > > sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti > rocker/r-ver:3.5.1 > > Could you please read the comments within the "Cairo Fonts" section of > the ?X11 help page, in case that offers some explanation. > > Paul > > > On 29/08/18 02:15, Martin Møller Skarbiniks Pedersen wrote: >> On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma >> wrote: >>> >>> In plotmath expressions, R's degree symbol, e.g. shown by >>> >>> plot(1, main = parse(text = "1*degree*C")) >>> >>> has sunk to halfway the text line, instead of touching its top. In older >>> R versions this looked much better. >> >> I can confirm this problem. >> >> R version 3.5.1 (2018-07-02) >> Platform: x86_64-pc-linux-gnu (64-bit) >> Running under: Ubuntu 18.04.1 LTS >> >> Matrix products: default >> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 >> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 >> >> locale: >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] compiler_3.5.1 >> >> __ >> 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
Re: [Rd] Request: make `var` a generic
Hi Kenny,
yes, there's only so much you can do with S3 methods penetrating other
packages' code; Iñaki discusses this in the blog about the r-quantities
project found at:
https://www.r-spatial.org/r/2018/08/31/quantities-final.html#fitting-linear-models-with-quantities
I'm not sure whether making "var" a generic would not shift the problem
to the next function not being generic, you could experiment with that.
On 1/20/19 6:39 PM, Kenny Bell wrote:
> Hi all,
>
> I am running into problems using `summary.lm` as calling `var` on a `units`
> object does not retain the `units` attribute.
>
> The units package addresses this issue for `mean` by implementing
> `mean.units`:
>
> units:::mean.units
> function (x, ...)
> {
> .as.units(NextMethod(), units(x))
> }
>
> This is, however, not possible for `var` (as it's not a generic), which
> breaks `summary.lm`:
>
> ```
> library(units)
> #> udunits system database from C:/R/Library/3.5/units/share/udunits
> iris$Sepal.Length <- set_units(iris$Sepal.Length, "cm")
>
> summary(lm(Sepal.Length ~ Sepal.Width,
>data = iris))
> #> Error in Ops.units(mean(f)^2, var(f)): both operands of the expression
> should be "units" objects
> ```
>
> Created on 2019-01-21 by the [reprex package](https://reprex.tidyverse.org)
> (v0.2.1.9000)
>
> Apologies if `stats` package emails shouldn't go here.
>
> Cheers,
> Kenny
>
> [[alternative HTML version deleted]]
>
> __
> 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
Re: [Rd] matplot.Date & matplot.POSIXct
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,] ad # [2,] be # 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
[Rd] S4 method dispatch
List,
In order to get rid of some old, unreadable S3 code in package sp, I'm
trying to rewrite things using S4 methods. Somewhere I fail, and I
cannot sort out why. In order to isolate the problem, I created two
functions, doNothing<- and dosth, and both should do nothing. The issue
is that in most cases they do nothing, but in some cases dosth(obj)
changes the class of obj and breaks with the error. I couldn't find a
pattern when this happens, but have a few cases where it consistently
breaks. Here's the code snippet:
setGeneric("doNothing<-", function(object, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing",
signature(object = "Spatial", value = "ANY"),
function(object, value) object)
dosth = function(obj) {
cl1 = class(obj)
doNothing(obj) = TRUE
cl2 = class(obj)
if (!identical(cl1, cl2)) {
print(paste(cl1, cl2))
stopifnot(identical(cl1, cl2))
}
obj
}
When things go wrong, dosth and doNothing are called with a subclass of
Spatial, e.g. an object of class SpatialGrid, but when this gets in
doNothing, the object is suddenly of class Spatial, and is then returned
as an object of class Spatial, which should never happen.
For instance, I have a case where consistently
setMethod("fullgrid", c("Spatial"),
function(obj) { is(obj, "SpatialGrid") })
> class(g)
[1] "SpatialGrid"
attr(,"package")
[1] "sp"
> fullgrid(g)
[1] FALSE
is obviously false, but in other cases it works fine.
When I change the signature of doNothing to signature(object = "ANY",
value = "ANY"), the problem disappears.
I tried to make a self-contained example that reproduced the issue, but
could only get something that worked as expected.
I would appreciate any help or suggestions.
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics e.pebe...@wwu.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 method dispatch
As a follow-up, I managed to isolate the problem I sent earlier this
week, and reduced it to a small case (I'm using R 2.13.1,
i486-pc-linux-gnu (32-bit)).
The following script does what I expect:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
and results in class(x) being "AB".
However, the following, very similar script:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
returns "A" as the class of x. Why is this the case? Is this behaviour
intentional?
Best regards,
On 09/14/2011 11:00 PM, Edzer Pebesma wrote:
> List,
>
> In order to get rid of some old, unreadable S3 code in package sp, I'm
> trying to rewrite things using S4 methods. Somewhere I fail, and I
> cannot sort out why. In order to isolate the problem, I created two
> functions, doNothing<- and dosth, and both should do nothing. The issue
> is that in most cases they do nothing, but in some cases dosth(obj)
> changes the class of obj and breaks with the error. I couldn't find a
> pattern when this happens, but have a few cases where it consistently
> breaks. Here's the code snippet:
>
> setGeneric("doNothing<-", function(object, value)
> standardGeneric("doNothing<-"))
>
> setReplaceMethod("doNothing",
> signature(object = "Spatial", value = "ANY"),
> function(object, value) object)
>
> dosth = function(obj) {
> cl1 = class(obj)
> doNothing(obj) = TRUE
> cl2 = class(obj)
> if (!identical(cl1, cl2)) {
> print(paste(cl1, cl2))
> stopifnot(identical(cl1, cl2))
> }
> obj
> }
>
> When things go wrong, dosth and doNothing are called with a subclass of
> Spatial, e.g. an object of class SpatialGrid, but when this gets in
> doNothing, the object is suddenly of class Spatial, and is then returned
> as an object of class Spatial, which should never happen.
>
> For instance, I have a case where consistently
>
> setMethod("fullgrid", c("Spatial"),
> function(obj) { is(obj, "SpatialGrid") })
>> class(g)
> [1] "SpatialGrid"
> attr(,"package")
> [1] "sp"
>> fullgrid(g)
> [1] FALSE
>
> is obviously false, but in other cases it works fine.
>
> When I change the signature of doNothing to signature(object = "ANY",
> value = "ANY"), the problem disappears.
>
> I tried to make a self-contained example that reproduced the issue, but
> could only get something that worked as expected.
>
> I would appreciate any help or suggestions.
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics e.pebe...@wwu.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 method dispatch
Thanks, John!
I did not manage to figure out how the strict= works, but changed class
inheritance such that simple inheritance did not take place.
I see you're advocating to use the contains= to stress inheritance; back
in 2005, I followed the green book, which did not yet have this.
If I now would change class definitions from using the representation=
into contains= to express inheritance, does the binary representation
also change, i.e. do people relying on sp classes get into problem with
old, saved objects read by the new software? I'm asking this because
there's lots of it around, e.g. all the world administrative regions
available as .RData files from http://gadm.org/ .
On 09/18/2011 11:04 PM, John Chambers wrote:
The distinction here is "simple inheritance" ("Software for Data
Analysis", p. 346). Your first example is simple inheritance (would be
clearer if you used the contains= argument). In the second version you
supply an explicit coerce method, so method dispatch can no longer just
pass in the object from the subclass, but has to call the coerce method
explicitly. Details in the reference.
If you need to have an explicit coerce method, it's possible to emulate
simple inheritance, but the programming may be more subtle than you want
to take on. When your method is called, it actually gets also an
argument strict= which will be FALSE for method dispatch. You need to
take account of the strict= argument in writing your method. See ?setAs
for a few more details. Someone on the list may have an example.
John
On 9/18/11 3:33 AM, Edzer Pebesma wrote:
As a follow-up, I managed to isolate the problem I sent earlier this
week, and reduced it to a small case (I'm using R 2.13.1,
i486-pc-linux-gnu (32-bit)).
The following script does what I expect:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
and results in class(x) being "AB".
However, the following, very similar script:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNothing<-", function(obj, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing", c("A", "character"),
function(obj, value) obj)
setAs("AB", "A", function(from) new("A", x = from@x))
x = new("AB", x = 10)
doNothing(x) = "irrelevant"
class(x)
returns "A" as the class of x. Why is this the case? Is this behaviour
intentional?
Best regards,
On 09/14/2011 11:00 PM, Edzer Pebesma wrote:
List,
In order to get rid of some old, unreadable S3 code in package sp, I'm
trying to rewrite things using S4 methods. Somewhere I fail, and I
cannot sort out why. In order to isolate the problem, I created two
functions, doNothing<- and dosth, and both should do nothing. The issue
is that in most cases they do nothing, but in some cases dosth(obj)
changes the class of obj and breaks with the error. I couldn't find a
pattern when this happens, but have a few cases where it consistently
breaks. Here's the code snippet:
setGeneric("doNothing<-", function(object, value)
standardGeneric("doNothing<-"))
setReplaceMethod("doNothing",
signature(object = "Spatial", value = "ANY"),
function(object, value) object)
dosth = function(obj) {
cl1 = class(obj)
doNothing(obj) = TRUE
cl2 = class(obj)
if (!identical(cl1, cl2)) {
print(paste(cl1, cl2))
stopifnot(identical(cl1, cl2))
}
obj
}
When things go wrong, dosth and doNothing are called with a subclass of
Spatial, e.g. an object of class SpatialGrid, but when this gets in
doNothing, the object is suddenly of class Spatial, and is then returned
as an object of class Spatial, which should never happen.
For instance, I have a case where consistently
setMethod("fullgrid", c("Spatial"),
function(obj) { is(obj, "SpatialGrid") })
class(g)
[1] "SpatialGrid"
attr(,"package")
[1] "sp"
fullgrid(g)
[1] FALSE
is obviously false, but in other cases it works fine.
When I change the signature of doNothing to signature(object = "ANY",
value = "ANY"), the problem disappears.
I tried to make a self-contained example that reproduced the issue, but
could only get something that worked as expected.
I would appreciate any help or suggestions.
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de
http://www.52north.org/geostatistics e.pebe...@wwu.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cumsum method in Math group
When running
a = runif(10)
class(a) = "foo"
Math.foo = function(x, ...) {
NextMethod(.Generic)
}
signif(a, 3)
cumsum(a)
I don't understand why cumsum strips the class, but signif does not.
Both claim in the documentation that "These are generic functions:
methods can be defined for them individually or via the ‘Math’ group
generic."
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software: http://www.jstatsoft.org/
Computers & Geosciences: http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Maintainer NOTE in R CMD Check
On 03/10/2014 04:42 PM, Gábor Csárdi wrote: > On Mon, Mar 10, 2014 at 11:36 AM, Hadley Wickham wrote: > >>>>> * checking CRAN incoming feasibility ... NOTE >>>>> Maintainer: 'firstname A B lastname ' >>> >>> >>> This is just a Note that reminds CRAN maintainers to check that the >>> submission comes actually from his maintainer and not anybody else. >> >> How does CRAN do that? Seems like a challenging problem given an >> anonymous web form upload. >> > > According to my memories, they send an email to the maintainer's email > address to confirm the upload. If the email address has changed, they send > an email to both the new and old addresses. > > If the old address does not exist any more, then it is tricky indeed, and I > am not sure what you can do in this case. > > Gabor Besides the effort it would involve, are there reasons why CRAN does not use a stronger package author identification mechanism, like web of trust (which debian uses) or public key infrastructure, and require packages to be signed? > > >> >> Hadley >> >> -- >> http://had.co.nz/ >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Heisenbergstraße 2, 48149 Münster, Germany. Phone: +49 251 83 33081 http://ifgi.uni-muenster.de GPG key ID 0xAC227795 signature.asc Description: OpenPGP digital signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Development Center(s)
A while ago our institute was approached by a large company, say XXX, who asked whether we would like to become an Xxx development center, as we are active in the same area. After some negotation we did, believing there will be mutual benefits. Some time later, after putting up the Xxx development center logo on the institute home page, my feeling grew that we are also, and probably to a larger extent, an R development center. However, this information is very hard to find out from the institute web site, particularly for prospective students who may not start off by looking at publication records. Identity, marketing, and logos are important these days. I realize there are many R Development Centers around the world. I wrote about what we (now) think makes us an R Development Center, at: http://giv-wikis.uni-muenster.de/agp/bin/view/Main/RDevelopmentCenter and I asked someone to develop a logo (two actually, one with CENTER, one with CENTRE). I believe it would be good for R if more R Development Centers would make explicit somehow that they are R Development Center, and maybe that a list of such centers can be found somewhere. We could use http://pad.ifgi.de/rdc as a start. Open source style, please feel free to reuse or modify the logo or ideas, and take the concept lightly. Next thing, when I'm concerned, would be to organize an RDC student of the year award. Any reactions welcome. With best wishes, -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de http://www.52north.org/geostatistics e.pebe...@wwu.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] how to check all CRAN dependencies for my package, before submitting
Suppose I'm author of a package on which quite a few other packages depend. When I submit to CRAN, I run R CMD check on it, Kurt does that too, and if things work out fine, it is accepted. When one or more of the packages that depend on it break because of my changes, however, hell breaks loose. I would like to extend my testing (currently: R CMD check pkg) to running R CMD check on all dependent packages, in their most recent (CRAN) version. I got stuck trying this. Does anyone know how to get (i) a list of all packages that depend, directly or indirectly, on my package, and (ii) a list of file names of their package sources in their latest version (i.e., including their latest version number)? -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de http://www.52north.org/geostatistics e.pebe...@wwu.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r-forge
On 02/08/2013 03:22 PM, Uwe Ligges wrote: Perhaps the R-forge results are outdated? Looks like the R-forge builds (and hence probably also the checks) are stuck since some days. Nice understatement. Several of my packages don't build on r-forge for some months now because some other packages are out of date on r-forge (far behind the CRAN version, for instance) or because of the obscure Error in setwd(libdir) : cannot change working directory error. I've written support requests, recieved answers, but haven't seen solutions. It seems I'm not the only one facing this. Maybe the r-forge team can tap into the potential of some of its 6000 users, assuming most of these are developers wanting a good, working system? Or are financial resources a problem? -- Edzer Pebesma Institute for Geoinformatics (ifgi), University of Münster Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251 8333081, Fax: +49 251 8339763 http://ifgi.uni-muenster.de http://www.52north.org/geostatistics e.pebe...@wwu.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
