[Rd] ggplot2/plyr interaction with latest R-devel?

Ben Bolker bbolker at gmail.com
Tue Sep 2 05:01:51 CEST 2014


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 <bbolker at 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 <bbolker at 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 <bbolker at 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 <cboettig at 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 <bbolker at 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 at 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]]



More information about the R-devel mailing list