From jmc at r-project.org  Fri Dec 11 19:11:05 2015
From: jmc at r-project.org (John Chambers)
Date: Fri, 11 Dec 2015 10:11:05 -0800
Subject: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
In-Reply-To: <22122.38537.382484.644230@stat.math.ethz.ch>
References: <CAOwKfPTq9TZaV6j9KxbpFuDpZdyskDB9egL7B911QP3oaR6vOw@mail.gmail.com>
	<56661824.9020707@gmail.com>
	<16F6D0AF-6667-45CF-9CBF-6BC19D514951@r-project.org>
	<22118.59473.654693.639907@stat.math.ethz.ch>
	<22122.38537.382484.644230@stat.math.ethz.ch>
Message-ID: <C5017517-991F-4C5B-A098-6DE85CBE0927@r-project.org>

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 that the third argument to as(), strict=TRUE by default.  So, yes, the change will cause all integer vectors to become double when the class extends "numeric".  Generally, strict=TRUE makes sense here and of course changing THAT would open up yet more incompatibilities.

For back compatibility, one would have to have some special code in setDataPart() for the case of integer/numeric.

John

(Historically, the original sin was probably not making a distinction between "numeric" as a virtual class and "double" as a type/class.)


On Dec 11, 2015, at 1:25 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:

>>>>>> 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 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 the expected result:
> 
>>>> setMethod("coerce", c("integer", "numeric"), getMethod("coerce", c("ANY", "numeric")))
>>> [1] "coerce"
>>>> typeof(as(1L, "numeric"))
>>> [1] "double"
> 
>>> Seems like a reasonable addition to the code, unless someone sees a problem.
>>> John
> 
>> I guess that that some package checks (in CRAN + Bioc + ... -
>> land) will break,
>> but I still think we should add such a coercion to R.
> 
>> Martin
> 
> Hmm...  I've tried to add the above to R
> and do notice that there are consequences that may be larger than
> anticipated:
> 
> Here is example code:
> 
>   myN   <- setClass("myN",   contains="numeric")
>   myNid <- setClass("myNid", contains="numeric", representation(id="character"))
>   NN <-    setClass("NN", representation(x="numeric"))
> 
>   (m1 <- myN  (1:3))
>   (m2 <- myNid(1:3, id = "i3"))
>   tools::assertError(NN (1:3))# in all R versions
> 
>   ##                     # current R  |  new R
>   ##                     # -----------|----------
>   class(getDataPart(m1)) # integer    |  numeric
>   class(getDataPart(m2)) # integer    |  numeric
> 
> 
> In other words, with the above setting, the traditional
> gentleperson's agreement in S and R,
> 
>  __ "numeric" sometimes conveniently means "integer" or "double"  __
> 
> will be slightly less often used ... which of course may be a
> very good thing.
> 
> However, it breaks strict back compatibility also in cases where
> the previous behavior may have been preferable:
> After all integer vectors need only have the space of doubles.
> 
> Shall we still go ahead and do apply this change to R-devel
> and then all package others will be willing to update where necessary?
> 
> As this may affect the many hundreds of bioconductor packages
> using S4 classes, I am -- exceptionally -- cross posting to the
> bioc-devel list.
> 
> Martin Maechler
> 
> 
>>> On Dec 7, 2015, at 3:37 PM, Benjamin Tyner <btyner at gmail.com> wrote:
> 
>>>> 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")
>>>>> 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", strict = TRUE)
>>>>> if (strict) {
>>>>> class(from) <- "numeric"
>>>>> from
>>>>> } else from
>>>>> 
>>>>> This in turn does nothing, even when strict=TRUE, because that
>>>>> assignment to class "numeric" has no effect:
>>>>> 
>>>>> x <- 10L
>>>>> class(x) <- "numeric"
>>>>> class(x)
>>>>> [1] "integer"
>>>>> 
>>>>> Is this the desired behavior for `as(x, "numeric")`?
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel


	[[alternative HTML version deleted]]



[Rd] For integer vectors, `as(x, "numeric")` has no effect.
John Chambers