On Tue, Jan 5, 2016 at 1:31 AM, Martin Maechler
wrote:
>> Josh O'Brien
>> on Mon, 4 Jan 2016 16:16:51 -0800 writes:
>
> > On Dec 19, 2015, at 3:32 AM, Martin Maechler stat.math.ethz.ch> wrote:
>
> >>> Martin Maechler on
> >>> Sat, 12 Dec 2015 10:32:51 +0100 w
> Josh O'Brien
> on Mon, 4 Jan 2016 16:16:51 -0800 writes:
> On Dec 19, 2015, at 3:32 AM, Martin Maechler wrote:
>>> Martin Maechler on
>>> Sat, 12 Dec 2015 10:32:51 +0100 writes:
>>
>>> John Chambers on Fri, 11 Dec
>>> 2015 10:11:05 -0800
On Dec 19, 2015, at 3:32 AM, Martin Maechler wrote:
>> 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 exam
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
> 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 intrigued me, so I looked into it a bit (should
> 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 intrigued me, so I looked into it a bit (should have been
doing something else, but )
> You're right that this is the
thz.ch]
Sent: Friday, December 11, 2015 4:25 AM
To: John Chambers; r-devel@r-project.org; bioc-devel list; Benjamin Tyner
Cc: Martin Maechler
Subject: Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
>>>>> Martin Maechler
>>>>> on Tue,
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 w
> 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 the generic function coerce()
but cannot use inhe
> 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 the generic function coerce() but
cannot use inheritance in the usual way (if it did, you would be immediately
back with no ch
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 co
Perhaps it is not that surprising, given that
> mode(1L)
[1] "numeric"
and
> is.numeric(1L)
[1] TRUE
On the other hand, this is curious, to say the least:
> is.double(as(1L, "double"))
[1] FALSE
Here's the surprising behavior:
x <- 1L
xx <- as(x, "numeric")
Here's the surprising behavior:
x <- 1L
xx <- as(x, "numeric")
class(xx)
## [1] "integer"
It occurs because the call to `as(x, "numeric")` dispatches the coerce
S4 method for the signature `c("integer", "numeric")`, whose body is
copied in below.
function (from, to = "numeric", s
13 matches
Mail list logo
