search for: coercions

On 04/13/2015 11:32 PM, Martin Maechler wrote: > >> Hi, >> > as.integer("5000000000") >> [1] 2147483647 >> Warning message: >> inaccurate integer conversion in coercion > >> > as.integer("-5000000000") >> [1] NA >> Warning message: >> inaccurate integer conversion in coercion >

Hi, > as.integer("5000000000") [1] 2147483647 Warning message: inaccurate integer conversion in coercion > as.integer("-5000000000") [1] NA Warning message: inaccurate integer conversion in coercion Is this a bug or a feature? The man page suggests it's the latter: ?as.integer? attempts to coerce its argument to be of integer type.

>>>>> Martin Maechler <maechler at lynne.stat.math.ethz.ch> >>>>> on Fri, 17 Apr 2015 15:49:35 +0200 writes: >>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 13 Apr 2015 23:36:14 -0700 writes: >> On 04/13/2015 11:32 PM, Martin Maechler wrote: >>> >>>> Hi,

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 13 Apr 2015 23:36:14 -0700 writes: > On 04/13/2015 11:32 PM, Martin Maechler wrote: >> >>> Hi, >>> > as.integer("5000000000") >>> [1] 2147483647 >>> Warning message: >>> inaccurate integer conversion in

Is there a way in R (12.x) to avoid the implicit coercion of factors to integers in the context of subscripts? If this is not possible, is there a way to get at least a warning, if any coercion of this type happens, given that the action of this coercion is almost never what is wanted? Of course, in the rare case that as.integer() is applied explicitly onto a factor, the warning is not needed,

Hi, I am looking into a way to hook into the R coercion framework to allow me to convert table-like data stored within a COM object into a data.frame. Some of our COM objects have their own table-like data storage, and from R's point of view it's an object (EXTPTRSXP) decoarated with a sepcial symbol so we can easily identify it. COM_Table <- a_method_that_creates_the_object()

Hi all, The coercion function defined for the ALTREP object will not be called by R when an assignment operation implicitly introduces coercion for a large ALTREP object. For example, If I create a vector of length 10, the ALTREP coercion function seems to work fine. ``` > x <- 1:10 > y <- wrap_altrep(x) > .Internal(inspect(y)) @0x000000001f9271c0 13 INTSXP g0c0 [REF(2)] I am

Hi Given that things like the following work > a <- c("-.1"," 2.7 ","B") > a [1] "-.1" " 2.7 " "B" > as.numeric(a) [1] -0.1 2.7 NA Warning message: NAs introduced by coercion > I naively expected that the following would behave differently. > b <- c('10%', '-20%', '30.0%',

Dear ALL I don't know why I can see this error in run this sentences. In paste("V", 1L:cols, sep = "") : NAs introduced by coercion DATA<-read.delim ("D:\\DATA\\GeneExpression.txt",header=FALSE) I will be glad if you help me. Best Regards, Stat Consult [[alternative HTML version deleted]]

How do I fix this error ? I tried coercion to a vector but that didn't work. msci <-read.csv("..MSCIexUS.csv", header=TRUE) head(msci) Date index 1 Dec 31, 1969 100 2 Jan 30, 1970 97.655 3 Feb 27, 1970 96.154 4 Mar 31, 1970 95.857 5 Apr 30, 1970 85.564 6 May 29, 1970 79.005 > str(msci) 'data.frame': 510 obs. of 2 variables: $ Date : Factor w/ 510

I work with Windows and use R version 2.4.1. I am JUST starting to learn this program... I get this warning message 'NAs introduced by coercion' while trying to build a distance matrix (to be analyzed with NMDS later) from a 336 x 100 data matrix. The original matrix has lots of zeros and no missing values, but I don't think this should matter. I searched this forum and people have

Hi I noticed a small inconsistency when using sum() vs cumsum() I have a char-based series > tryjpy$long [1] "0.0022" "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" "-0.0022" [8] "0.0003" "-0.0001" "-0.0004" "-0.0036" "-0.001" "-0.0011"

Hi Gabriel, here is a simple package for reproducing the problem. https://github.com/Jiefei-Wang/testPkg Best, Jiefei On Thu, Oct 8, 2020 at 5:04 AM Gabriel Becker <gabembecker at gmail.com> wrote: > Jiefei, > > Where does the code for your altrep class live? > > Thanks, > ~G > > On Wed, Oct 7, 2020 at 4:25 AM Jiefei Wang <szwjf08 at gmail.com> wrote: >

Hi, I have a dataframe that I imported from a .txt file by: skogTemp <- read.delim2("Skogaryd_shoot_data.txt", header=TRUE, fill=TRUE) and the data are factors, how can avoid factors from the beginning? Although the file contains both characters and numbers. I tried to convert some of the columns from factor to numeric and as I understood it you can not use only as.numeric but

Hello, I have two related ALTREP questions. It seems like there is no way to assign attributes to an ALTREP vector without using C++ code. To be more specifically, I want to make an ALTREP matrix, I have tried the following R code but none of them work. ``` .Internal(inspect(1:6)) .Internal(inspect(matrix(1:6, 2,3))) .Internal(inspect(as.matrix(1:6))) .Internal(inspect(structure(1:6, dim =

Hi R users I am wondering how I can avoid automatic coercion of my numeric vector elements to character init <- c(age='N', R=as.numeric(0.5), S=as.numeric(0.8)) I have used as.numeric() but it does not seem to work Thank you Lorenzo [[alternative HTML version deleted]]

Hi, i am trying to run an ANCOVA and a bootstrapped ANCOVA analysis on a specific data set. I am using the ancova and ancboot functions as in the following code: setwd("C:/Users/User/Desktop/Rdatabilingualstudy2012") bilingualismdata<-read.spss("bilingualdataforconferences2012.sav", use.value.labels = TRUE, to.data.frame = TRUE)

>>>>> Tomas Kalibera >>>>> on Tue, 25 Aug 2020 09:29:05 +0200 writes: > On 8/23/20 5:02 PM, Rory Winston wrote: >> Hi >> >> I noticed a small inconsistency when using sum() vs cumsum() >> >> I have a char-based series >> >> > tryjpy$long >> >> [1]

Hi, there was a memory improvement done in R going from R 3.3.3 to R 3.4.0 when it comes to comparing an integer 'x' an double 'y' (either may be scalar or vector). For example, in R 3.3.3, I get: > getRversion() [1] '3.3.3' > x <- integer(1000) > y <- double(1000) > profmem::profmem(z <- (x < y)) Rprofmem memory profiling of: z <- (x < y)

I just meant that the minimal contract for as.list() appears to be that it returns a VECSXP. To the user, we might say that is.list() will always return TRUE. I'm not sure we can expect consistency across methods beyond that, nor is it feasible at this point to match the semantics of the methods package. It deals in "class space" while as.list() deals in "typeof() space".