Re: [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 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 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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
In addition to what Charles wrote, you can also use 'local' if you don't
want a function that creates another function.
> f <- local({info <- 10; function(x) x + info})
> f(3)
[1] 13
best,
Mark
Op vr 11 dec. 2015 om 03:27 schreef Charles C. Berry :
> On Thu, 10 Dec 2015, Konrad Rudolph wrote:
>
> > I’ve got the following scenario: I need to store information about an
> > R function, and retrieve it at a later point. In other programming
> > languages I’d implement this using a dictionary with the functions as
> > keys. In R, I’d usually use `attr(f, 'some-name')`. However, for my
> > purposes I do not want to use `attr` because the information that I
> > want to store is an implementation detail that should be hidden from
> > the user of the function (and, just as importantly, it shouldn’t
> > clutter the display when the function is printed on the console).
> >
> > `comment` would be almost perfect since it’s hidden from the output
> > when printing a function — unfortunately, the information I’m storing
> > is not a character string (it’s in fact an environment), so I cannot
> > use `comment`.
> >
> > How can this be achieved?
> >
>
> See
>
> https://cran.r-project.org/doc/manuals/r-release/R-intro.html#Scope
>
> For example, these commands:
>
> foo <- function() {info <- "abc";function(x) x+1}
> func <- foo()
> find("func")
> func(1)
> ls(envir=environment(func))
> get("info",environment(func))
> func
>
> Yield these printed results:
>
> : [1] ".GlobalEnv"
> : [1] 2
> : [1] "info"
> : [1] "abc"
> : function (x)
> : x + 1
> :
>
> The environment of the function gets printed, but 'info' and other
> objects that might exist in that environment do not get printed unless
> you explicitly call for them.
>
> HTH,
>
> Chuck
>
> p.s. 'environment(func)$info' also works.
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-devel, autotools and libtool
Hello all,
I have spent the last week going through the configure/configure.ac
file, basically line-by-line.
I am finding things related to AIX that have not been working well
(i.e., cleanly) for 32-bit builds and are a "root-cause" for 64-bit
builds to finish cleanly.
Trying to keep this short - you can also just skip to end to see my
question!
With regard to AIX, there is a lot of difficulty re: 64-bit and default
libraries.
a) AIX aka IBM built-libraries contain both 32 and 64 bit members, so
there is no need for lib64
b) AIX Toolbox (-like) distros, built on GCC do have 32 and 64 bit
directories, and while they may use lib64 the gcc compiler uses ppc64
for it's 64-bit libraries. "Happy standardization"
c) IMHO - as I cannot speak for IBM - the "preference" for AIX is to not
use /usr/local (Someone, maybe it
was BULL, opted for /opt/freeware as a prefix. That is where AIXTOOLBOX
(family) install files. And the fun here is - some packages have mixed
32 and 64 bit members, others use the lib64 convention.
In any case, forcing /usr/local (when $prefix is defined to something
else) may break things (it has in earlier 'package' builds at least.)
and the way it is now, /usr/local gets put in front of anything else).
${rhome} - not 'simple' to find where it is defined (not in config.ac,
not in m4/R.m4 - that I understand)
Guessing here, but for 64-bit I expect this may be introducing one of
the problems I have had:
## As from R 3.2.0 split up -L... and -lR
if test "${want_R_shlib}" = yes; then
LIBR0="-L\$(R_HOME)/lib\$(R_ARCH)"
LIBR1=-lR
else
LIBR0=
LIBR1=
fi
And then, ignoring the rest until I get to:
##
## Completely disable using libtool for building shlibs until libtool
## fully supports Fortran and C++.
## AC_ARG_WITH([libtool],
## [AS_HELP_STRING([--with-libtool],[use libtool for building shared
libraries [yes]])],
## [use_libtool="${withval}"],
## [use_libtool=yes])
## AM_CONDITIONAL(USE_LIBTOOL, [test "x${use_libtool}" = xyes])
##
Hence the question - is there a real interest on someone (like me) to
examine libtool usage on a slightly used platform?
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Runtime error when run a RInside program compiled by intel c++ on windows
I have intstalled R-3.2.2,Rcpp-0.12.2,RInside-0.2.13 on windows. I compiled
the example1 of RInside in the
example directory which create a RInside instance and prints "hello world". The
compiler is intel c++. I included
the RInside source files in the project and fixed the compile and link errors.
But when run the executable file it
prints some error message and quites.
I debug into the code.The error messages come from the RInside::initialize()
function. It gives following message after
Rf_initEmbeddedR():
Warning message:
In local(( :bytecode version mismatch: using eval
Error in objects(db.pos, all.name = TRUE) :
3 arguments passed to .Internal(ls) which requres 2
And it gives following error after
Rf_eval(Rf_lang2(suppressMessagesSymbol,Rf_lang2(requireSymbol,
Rf_mkString("Rcpp"))),R_GlobalEnv)
Error in .Internal(getOption(x)):
there is no .Internal function 'getOption'
Execution halted.
Does anyone know how to fix this error? Thanks.
Eric
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
Thanks. I know about `local` (and functions within functions). In
fact, the functions are *already* defined inside their own environment
(same as what `local` does). But unfortunately this doesn’t solve my
problem, since the functions’ parent environment gets changed during
the function’s execution, and I need to retrieve my stored data
*after* that point, inside the function.
I’ve tried to create a more exact example of what’s going on —
unfortunately it’s really hard to simplify the problem without losing
crucial details. Since the code is just a tad too long, I’ve posted it
as a Github Gist:
https://gist.github.com/klmr/53c9400e832d7fd9ea5c
The function `f` in the example calls `get_meta()` twice, and gets
different results before and after calling an ancillary function that
modifies the function’s `parent.env`. I want it to return the same
information (“original”) both times.
On Fri, Dec 11, 2015 at 10:49 AM, Mark van der Loo
wrote:
> In addition to what Charles wrote, you can also use 'local' if you don't
> want a function that creates another function.
>
>> f <- local({info <- 10; function(x) x + info})
>> f(3)
> [1] 13
>
> best,
> Mark
>
>
> Op vr 11 dec. 2015 om 03:27 schreef Charles C. Berry :
>>
>> On Thu, 10 Dec 2015, Konrad Rudolph wrote:
>>
>> > I’ve got the following scenario: I need to store information about an
>> > R function, and retrieve it at a later point. In other programming
>> > languages I’d implement this using a dictionary with the functions as
>> > keys. In R, I’d usually use `attr(f, 'some-name')`. However, for my
>> > purposes I do not want to use `attr` because the information that I
>> > want to store is an implementation detail that should be hidden from
>> > the user of the function (and, just as importantly, it shouldn’t
>> > clutter the display when the function is printed on the console).
>> >
>> > `comment` would be almost perfect since it’s hidden from the output
>> > when printing a function — unfortunately, the information I’m storing
>> > is not a character string (it’s in fact an environment), so I cannot
>> > use `comment`.
>> >
>> > How can this be achieved?
>> >
>>
>> See
>>
>> https://cran.r-project.org/doc/manuals/r-release/R-intro.html#Scope
>>
>> For example, these commands:
>>
>> foo <- function() {info <- "abc";function(x) x+1}
>> func <- foo()
>> find("func")
>> func(1)
>> ls(envir=environment(func))
>> get("info",environment(func))
>> func
>>
>> Yield these printed results:
>>
>> : [1] ".GlobalEnv"
>> : [1] 2
>> : [1] "info"
>> : [1] "abc"
>> : function (x)
>> : x + 1
>> :
>>
>> The environment of the function gets printed, but 'info' and other
>> objects that might exist in that environment do not get printed unless
>> you explicitly call for them.
>>
>> HTH,
>>
>> Chuck
>>
>> p.s. 'environment(func)$info' also works.
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
On Thu, Dec 10, 2015 at 5:49 PM, Konrad Rudolph wrote: > I’ve got the following scenario: I need to store information about an > R function, and retrieve it at a later point. In other programming > languages I’d implement this using a dictionary with the functions as > keys. In R, I’d usually use `attr(f, 'some-name')`. However, for my > purposes I do not want to use `attr` because the information that I > want to store is an implementation detail that should be hidden from > the user of the function (and, just as importantly, it shouldn’t > clutter the display when the function is printed on the console). > > `comment` would be almost perfect since it’s hidden from the output > when printing a function — unfortunately, the information I’m storing > is not a character string (it’s in fact an environment), so I cannot > use `comment`. > > How can this be achieved? > > For reference, I’ve considered the following two alternatives: > > 1. Use `attr`, and override `print.function` to not print my > attribute. However, I’m wary of overriding a core function just to > implement such a little thing, and overriding this function would > obviously clash with other overrides, if somebody else happens to have > a similarly harebrain idea. Why not use your own S3 class? Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runtime error when run a RInside program compiled by intel c++ on windows
Eric,
This must now be your third or fourth email on this matter (counting the one
to me directly, and to be clear I much prefer this on list). I'll be brief:
On 11 December 2015 at 20:50, 李琥 wrote:
|
| I have intstalled R-3.2.2,Rcpp-0.12.2,RInside-0.2.13 on windows. I compiled
the example1 of RInside in the
| example directory which create a RInside instance and prints "hello world".
The compiler is intel c++. I included
| the RInside source files in the project and fixed the compile and link
errors. But when run the executable file it
| prints some error message and quites.
|I debug into the code.The error messages come from the
RInside::initialize() function. It gives following message after
| Rf_initEmbeddedR():
|
| Warning message:
| In local(( :bytecode version mismatch: using eval
| Error in objects(db.pos, all.name = TRUE) :
|3 arguments passed to .Internal(ls) which requres 2
|
| And it gives following error after
Rf_eval(Rf_lang2(suppressMessagesSymbol,Rf_lang2(requireSymbol,
Rf_mkString("Rcpp"))),R_GlobalEnv)
|
| Error in .Internal(getOption(x)):
| there is no .Internal function 'getOption'
| Execution halted.
|
| Does anyone know how to fix this error? Thanks.
This is rather indicative of an unsuccessful build.
You may have managed to link this in some, but R clearly does not instantiate
right and does not start right. getOption() is part of the base package. If
that goes astray you have /a lot more/ problems to expect.
So if I were you, I'd reverse course and forget icc. R, Rcpp, RInside are all
tested against a well known set of compilers __and work with those__. So on
Windows I would stick with MinGW.
Lastly, as the Rcpp + RInside documentation says in several places: please
ask on the rcpp-devel list.
R-devel is not the correct forum for questions with particular packages.
Thanks, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
On Fri, Dec 11, 2015 at 12:49 AM, Konrad Rudolph
wrote:
>
> On the chance that I’m trying to solve the wrong Y to an X/Y problem,
> the full context to the above problem is explained in [1]. In a
> nutshell, I am hooking a new environment into a function’s parent.env
> chain, by re-assigning the function’s `parent.env` (naughty, I know).
> This is done so that the function `f` finds objects defined inside
> that environment without having to attach it globally.
Not sure if this is helpful, but you can implement this more naturally
using closures without hacking on environments. As I understand it,
your functions have some shared state, and some private. So each
function needs a private parent env, which all share a common
grand-parent that holds your shared objects. Maybe this example helps:
new_closure <- (function(shared = 0){
function(name, priv = 0){
function(){
priv <<- priv +1
shared <<- shared +1
print(sprintf("Total:%d; %s:%d", shared, name, priv))
}
}
})()
fun1 <- new_closure("erik")
fun2 <- new_closure("anna")
fun1()
fun1()
fun1()
fun2()
fun1()
fun1()
fun2()
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
@Jeroen, here’s what I’m solving with my hacking the parent environment chain: I’m essentially re-implementing `base::attach` — except that I’m attaching objects *locally* in the function instead of globally. I don’t think this can be done in any way except by modifying the parent environment chain. Incidentally, package namespaces do largely the same thing. The difference is that they only need to do it *once* (when loaded), and subsequent function calls do not modify this chain. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do I reliably and efficiently hash a function?
On Fri, Dec 11, 2015 at 1:26 PM, Hadley Wickham wrote: > Why not use your own S3 class? Yes, I’ll probably do that. Thanks. I honestly don’t know why I hadn’t thought of that before, since I’m doing the exact same thing in another context [1]. [1]: https://github.com/klmr/decorator/blob/2742b398c841bac53acb6607a4d220aedf10c26b/decorate.r#L24-L36 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [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 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 wrote:
>> 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 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 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
Re: [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]
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, 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 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 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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
This email message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited. If you have received
this message in err
