One more correction: the relevant change seems to be https://github.com/wch/r-source/commit/7681eefd37e7fa4da877b267c006df839303680c or
or r66230 | hornik | 2014-07-22 17:14:31 -0400 (Tue, 22 Jul 2014) | 2 lines Have .encode_numeric_version() use strings of octals rather than double precision p-adic rationals. On Mon, Sep 1, 2014 at 9:38 PM, Ben Bolker <bbol...@gmail.com> wrote: > PS this is on i686-pc-linux-gnu (32-bit). On x86_64-apple-darwin10.8.0, > log(8,base=8)==1 is TRUE, so I'm guessing the problem wouldn't come up. > > (At this point I believe the problem occurs if (and only?) if > log(8,base==8)==1 is FALSE, *and* you try to make a comparison that > involves a package version with an 8 in it ...) > > > > On Mon, Sep 1, 2014 at 9:27 PM, Ben Bolker <bbol...@gmail.com> wrote: > >> Further losing my marbles. I *think* this is a subtle bug in the >> comparison operator for package_version objects that will be dependent on >> small (platform-dependent) numerical computation differences, possibly >> (???) introduced in r66259. >> >> If I have not completely lost it (which is entirely possible), the >> problem stems from the fact that floor(log(8,base=8L)) is 0 rather than 1 >> on my machine, since log(8,base=8L) is slightly less than 1 rather than >> equal to 1. All of the following possibly entertaining code comes from >> excavating the guts of src/library/base/R/version.R : this file was changed >> on July 27 < >> https://github.com/wch/r-source/commit/ce6732242c0757e07ebc4a5efb7d210cba6a0cfa> >> , which makes me suspicious, but I don't see directly how the modifications >> would have broken this. >> >> ## basic sanity-test of package version comparison >> as.package_version("1.0.0")>=as.package_version("0.9.9") ## TRUE >> >> ## the specific comparison I'm trying to make: >> (e1 <- as.package_version("1.8.1"))>=(e2 <- as.package_version("1.7.1")) >> ## FALSE (!!!) >> unclass(e1) ## 1 8 1 >> unclass(e2) ## 1 7 1 >> >> ## part of the internal function operation .encode_numeric_version >> intwid <- log(max(unlist(e1), unlist(e2), 1L, na.rm = TRUE), base = 8L) >> ## (why base 8? Tom Lehrer: "base eight is just like base ten really if >> you're missing two fingers") >> ## I can see that we're sprintf()ing the results in octal a few lines >> later ...) >> ## 1 -- looks OK, but: >> >> intwid-1 ## [1] -1.110223e-16 >> width <- floor(intwid) + 1L ## this is the calculation that actually >> gets done: >> ## >> ## 1 ## should be 2 >> >> log(8, base=8L)-1 >> log(8, base=8)-1 >> logvals <- setNames(log(2:25,base=2:25)-1,2:25) >> logvals[logvals!=0] ## 5,8,14,18,19,25 all == .Machine$double.eps/2 >> >> >> w1 <- .encode_numeric_version(e1, width = width, maxlen = maxlen) ## >> "1101" >> w2 <- .encode_numeric_version(e2, width = width, maxlen = maxlen) ## "171" >> w1>w2 ## FALSE >> >> w1A <- .encode_numeric_version(e1, width = 2, maxlen = maxlen) ## "011001" >> w2A <- .encode_numeric_version(e2, width = 2, maxlen = maxlen) ## "010701" >> w1A>w2A ## TRUE >> >> >> If I had the patience I would revert to before this SVN change and see >> what happened: >> >> ================= >> r66259 | hornik | 2014-07-27 15:45:29 -0400 (Sun, 27 Jul 2014) | 2 lines >> >> Have .encode_numeric_version() pad to common length with trailing zeros. >> Add [<-.numeric_version(). >> >> >> >> >> On Mon, Sep 1, 2014 at 4:16 PM, Ben Bolker <bbol...@gmail.com> wrote: >> >>> thanks -- although I think `dplyr` is a red herring; my issue is with >>> `plyr` (which is imported by `ggplot2` so should get installed >>> automatically anyway ...) >>> >>> >>> On Mon, Sep 1, 2014 at 4:08 PM, Carl Boettiger <cboet...@gmail.com> >>> wrote: >>> >>>> Hi Ben, >>>> >>>> Just tested this on a fresh ubuntu 14:04 sandbox by using Dirk's docker >>>> image ( >>>> https://github.com/eddelbuettel/docker-ubuntu-r/tree/master/add-r-devel-san) >>>> for Rdevel. >>>> >>>> > install.packages(c("dplyr", "ggplot2")) >>>> > library("dplyr") >>>> > library("ggplot2") >>>> >>>> runs fine for me (though takes a few minutes to compile everything). So >>>> it seems you must have done something to your local environment, but not >>>> sure what. >>>> >>>> >>>> >>>> >>>> On Mon, Sep 1, 2014 at 11:42 AM, Ben Bolker <bbol...@gmail.com> wrote: >>>> >>>>> >>>>> I apologize in advance for not having done more homework in advance, >>>>> but thought I would send this along to see if anyone else was seeing >>>>> this. >>>>> >>>>> I am having some sort of ggplot2/plyr/very-recent-R-devel dependency >>>>> issues. >>>>> >>>>> Just installed >>>>> >>>>> R Under development (unstable) (2014-09-01 r66509) -- "Unsuffered >>>>> Consequences" >>>>> >>>>> from source. >>>>> >>>>> > packageVersion("ggplot2") >>>>> [1] ‘1.0.0’ >>>>> > packageVersion("plyr") >>>>> [1] ‘1.8.1’ >>>>> >>>>> library(plyr) works >>>>> >>>>> but then I get: >>>>> >>>>> library(ggplot2) >>>>> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = >>>>> vI[[i]]) : >>>>> namespace ‘plyr’ 1.8.1 is being loaded, but >= 1.7.1 is required >>>>> Error: package or namespace load failed for ‘ggplot2’ >>>>> >>>>> I don't remember when I most recently updated my r-devel (it was >>>>> probably a few months old); nothing in recent commits rings a bell. >>>>> >>>>> Works fine on R version 3.1.1 (except for a "ggplot2 built under >>>>> 3.2.0 warning"). >>>>> >>>>> Does anyone else see this or is it just something weird about my >>>>> setup? >>>>> >>>>> Ben Bolker >>>>> >>>>> ______________________________________________ >>>>> R-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>> >>>> >>>> >>>> >>>> -- >>>> Carl Boettiger >>>> UC Santa Cruz >>>> http://carlboettiger.info/ >>>> >>> >>> >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
