Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

Re: coerce() methods. Important to realize that as() does not call selectMethod() in the standard way, but restricts inheritance to the first argument: asMethod <- selectMethod("coerce", sig, optional = TRUE, c(from = TRUE, to = FALSE), fdef = coerceFun, A

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

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

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

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

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

> Martin Maechler > on Sat, 12 Dec 2015 10:32:51 +0100 writes: > John Chambers > on Fri, 11 Dec 2015 10:11:05 -0800 writes: >> Somehow, the most obvious fixes are always back-incompatible these days. >> The example

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

> Martin Maechler > on Tue, 8 Dec 2015 15:25:21 +0100 writes: > John Chambers > 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

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

>From the Bioconductor side of things, the general feeling is that this is a >step in the right direction and worth the broken packages. Martin Morgan From: R-devel [r-devel-boun...@r-project.org] on behalf of Martin Maechler [maech...@stat.math.ethz.ch]

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

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