similar to: For integer vectors, `as(x, "numeric")` has no effect.

We do need an explicit method here, I think. The issue is that as() uses methods for the generic function coerce() but cannot use inheritance in the usual way (if it did, you would be immediately back with no change, since "integer" inherits from "numeric"). Copying in the general method for coercing to "numeric" as an explicit method for "integer" gives

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 8 Dec 2015 15:25:21 +0100 writes: >>>>> John Chambers <jmc at r-project.org> >>>>> on Mon, 7 Dec 2015 16:05:59 -0800 writes: >> We do need an explicit method here, I think. >> The issue is that as() uses methods for the generic

>>>>> John Chambers <jmc at r-project.org> >>>>> on Fri, 11 Dec 2015 10:11:05 -0800 writes: > Somehow, the most obvious fixes are always back-incompatible these days. > The example intrigued me, so I looked into it a bit (should have been doing something else, but ....) > You're right that this is the proverbial

As I tried to say on Dec. 11, there are two levels of "fix": 1. The fix to the complaint in the OP's subject heading is to conform to the default third argument, strict=TRUE: as(1L, "numeric") == 1.0 This generates some incompatibilities, as for classes that extend "numeric". But still leaves class(1.0) "numeric" and typeof(1.0) "double".

On Dec 19, 2015, at 3:32 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>>> on Sat, 12 Dec 2015 10:32:51 +0100 writes: > >>>>>> John Chambers <jmc at r-project.org> >>>>>> on Fri, 11 Dec 2015 10:11:05 -0800 writes: >

>>>>> John Chambers <jmc at r-project.org> >>>>> on Mon, 7 Dec 2015 16:05:59 -0800 writes: > We do need an explicit method here, I think. > The issue is that as() uses methods for the generic function coerce() but cannot use inheritance in the usual way (if it did, you would be immediately back with no change, since "integer"

Somehow, the most obvious fixes are always back-incompatible these days. The example intrigued me, so I looked into it a bit (should have been doing something else, but ....) You're right that this is the proverbial thin-edge-of-the-wedge. The problem is in setDataPart(), which will be called whenever a class extends one of the vector types. It does as(value, dataClass) The key point is

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Sat, 12 Dec 2015 10:32:51 +0100 writes: >>>>> John Chambers <jmc at r-project.org> >>>>> on Fri, 11 Dec 2015 10:11:05 -0800 writes: >> Somehow, the most obvious fixes are always back-incompatible these days. >> The example intrigued

Or maybe the "right" concept is that "numeric" is a virtual class with 3 subclasses: "complex", "double", and "integer". Anyway it's probably too late for implementing the "right" concept so it doesn't really matter. Thanks Martin for offering to fix the as(1L, "numeric") bug. Very much appreciated. I guess that means

>>>>> Josh O'Brien <joshmobrien at gmail.com> >>>>> on Mon, 4 Jan 2016 16:16:51 -0800 writes: > On Dec 19, 2015, at 3:32 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>>> Martin Maechler <maechler at stat.math.ethz.ch> on >>>>>>> Sat, 12 Dec 2015 10:32:51 +0100

I was hoping to fit along the lines of g<-gl(20,5) y<-runif(100) fit<-lme(fixed=y~g,correlation=corAR1(0,~1|g)) But I get the error "Incompatible formulas for groups in "random" and "correlation"" Any help would be greatly appreciated. Ben

Hi, > class(as(1:4, "numeric")) [1] "integer" Surprising but an explanation could be that an integer vector being a particular case of numeric vector, this coercion has nothing to do because 1:4 is already numeric. And indeed: > is.numeric(1:4) [1] TRUE > is.numeric(as(1:4, "numeric")) [1] TRUE However, 'as(1:4,

Not sure if this is a bug, so posting here first. If I run: ?? cnt <- 0L ?? while (TRUE) { ? ? ?? cnt <- cnt + 1L ? ? ?? p <- pipe("echo /dev/stdin > /dev/null", open = "w") ? ? ?? writeLines("foobar", p) ? ? ?? tryCatch(close(p), error = function(e) { print(cnt); stop(e)}) ?? } then once cnt gets to around 650, it fails with: ?? [1] 654 ??

Full_Name: Benjamin Tyner Version: 2.3.0 OS: linux-gnu (debian) Submission from: (NULL) (71.98.75.54) > mean(NA) returns -2147483648 on my system, which is -(1+.Machine$integer.max) > sessionInfo() Version 2.3.0 (2006-04-24) i686-pc-linux-gnu attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils"

Andreas, How right you are! Still, I find it curious that in the context of the while(TRUE) loop, I am allowed to do this 653 times, with failure on the 654th attempt. Perhaps there is something asynchronous going on? If I eliminate the looping, it does indeed fail (as expected) on the first attempt to close the pipe. Regards Ben On 12/6/19 2:04 AM, Andreas Kersting wrote: > Hi

(I think this is being caused by the new methods package in RC.) In the RC (March 24) some of my packages are generating a Note Note: Method with signature "MySQLConnection#integer" chosen for function "coerce", target signature "TSMySQLConnection#integer". "dbObjectId#integer" would also be valid This is coming from a call to dbGetQuery() in package

A kind member of R-core suggested this is due to a misconfiguration on my system, and to post it to the mailing list for troubleshooting. When trying to build R version 4.3.3, in at least two places during the process it gives LaTeX errors of the form: (example 1) you should 'make docs' now ... make[1]: Entering directory '/home/btyner/R-4.3.3/doc' creating

I didn't do the compile; is there a way to check whether that was used? If not, I'll inquire with our sysadmin and report back. In any case, my suggestion was motivated by the fact that some parts of R use OpenMP while others do not, in the hope that the former could have their OpenBLAS omelet without breaking the OpenMP eggs, so to speak. On 01/09/2018 06:41 PM, Keith O'Hara

Hi Does rJava offer a way to instruct the JVM to perform a garbage collection? Regards Ben

Full_Name: Ben Tyner Version: 2.2.0 OS: i686-pc-linux-gnu Submission from: (NULL) (128.210.141.240) My appologies if this has already been fixed, but I didn't see it in the tracking system yet so I thought I'd report it. Demonstration: xyplot(Petal.Length ~ Petal.Width | Species, iris, strip = strip.custom(style = 1, var.name = expression(beta),