similar to: Possible issue with coercion in sprintf()?

I initially thought this is "documented behaviour". ?sprintf says: Numeric variables with __exactly integer__ values will be coerced to integer. (emphasis mine). Turns out this only works when the first value is numeric and not NA, as shown by the following example: > sprintf("%d", as.numeric(c(NA,1))) Error in sprintf("%d", as.numeric(c(NA, 1))) : invalid

Yes, what Joris posts about is exactly what I noted in my March 9th post to R-devel. The behaviour is sort of documented, but not in the clearest manner (in my opinion). Like I say, my ultimate conclusion was that the silent coercion of numerics to integers by sprintf() was a handy convenience, but not one that should be relied about to always work predictably. On Tue, May 23, 2017 at 10:02 AM,

Astute observation. And of course we should be passing integer when we use %d. It's an edge case in how we printed ITime objects in data.table: On Tue, May 23, 2017 at 11:53 AM, Joris Meys <jorismeys at gmail.com> wrote: > I initially thought this is "documented behaviour". ?sprintf says: > > Numeric variables with __exactly integer__ values will be coerced to >

https://github.com/Rdatatable/data.table/issues/2171 The fix was easy, it's just surprising to see the behavior change almost on a whim. Just wanted to point it out in case this is unknown behavior, but Evan seems to have found this as well. On Tue, May 23, 2017 at 12:00 PM, Michael Chirico <michaelchirico4 at gmail.com > wrote: > Astute observation. And of course we should be

Hi Michael, I posted something on this topic to R-devel several weeks ago, but never got a response. My ultimate conclusion is that sprintf() isn't super consistent in how it handles coercion: sometimes it'll coerce real to integer without complaint, other times it won't. (My particular email had to do with the vectors longer than 1 and their positioning vis-a-vis the format string.)

Consider #as.numeric for emphasis sprintf('%d', as.numeric(1)) # [1] "1" vs. sprintf('%d', NA_real_) > Error in sprintf("%d", NA_real_) : invalid format '%d'; use format %f, %e, %g or %a for numeric object > I understand the error is correct, but if it works for other numeric input, why doesn't R just coerce NA_real_ to NA_integer_?

I found this as well. At our institution, our home directories are on network shares that are mapped to local drives. The default, it appears, is to set the location for libraries (etc) to the network share name (//computer//share/director/a/b/user) rather than the local drive mapping (H:/). Given the issue with dir.create(), this means it's impossible to install packages (since it tries to

>>>>> Evan Cortens <ecortens at mtroyal.ca> >>>>> on Thu, 17 Nov 2016 15:51:03 -0700 writes: > I wonder if this could be related to the issue that I > submitted to bugzilla about two months ago? ( > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) > That is to say, could it be that it's treating the first >

In researching another issue, I discovered a workaround: the network drive folder needs to be mapped to the local PC. setwd("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/Michael Laviolette/Stat tools") df1 <- readxl::read_excel("addrlist-4-MikeL.xls", 2) # fails, throws same error df2 <- readxl::read_excel("Z:/Stat

Hi folks, I've noticed that there's an issue with the recursive creation of directories that reside on network shares. For example: > dir.create('\\\\SERVERNAME\\Empl\\Home1\\active\\e\\ecortens\\thisisatest', recursive = TRUE) Warning message: In dir.create("\\\\SERVERNAME\\Empl\\Home1\\active\\e\\ecortens\\thisisatest", : cannot create dir

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 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

I wonder if this could be related to the issue that I submitted to bugzilla about two months ago? ( https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159) That is to say, could it be that it's treating the first path after the single backslash as an actual directory, rather than as the name of the share? -- Evan Cortens, PhD Institutional Analyst - Office of Institutional Analysis

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 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: >

The packages "readxl" and "haven" (and possibly others) no longer access files on shared network drives. The problem appears to be in the normalizePath() function. The file can be read from a local drive or by functions that don't call normalizePath(). The error thrown is Error: path[1]="\\Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls": The system cannot find the

When something is assigned to an element of a vector that was previously of length 0, the vector is coerced to the mode of the something, regardless of whether the coercion is necessary under normal R rules. In particular, if NA is assigned to an element of a vector that was previously length 0, the mode of the vector is coerced to 'logical'. For example, here's the normal behaviour:

I need to convert a dataframe to a record-structure, to be able to encode it later in JSON. Suppose this is the data: mydata <- data.frame(foo=1:3, bar=c("M","M","F")); I would like to convert this to a unnamed list (json array) of key-value pairs. For example like this: apply(data.frame(foo=1:3, bar=c("M","M","F")),1,as.list)

The attached diff address the following issues in mclapply mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be an efficient representation and is not required if the object implements length, [, and [[ methods (lapply must also work on the object, either through coercion to a list at the 'inner.do' level or through other means, e.g., promoting lapply to a

Should functions or the user be responsible for coercing an S4 object argument containing the proper object (and thus should below be considered a bug in the packages or not)? The example is with RSQLite but the same thing happens with RMySQL, and other DBI packages. > library("RSQLite") Loading required package: DBI > m <- dbDriver("SQLite") > con <-

>>>>> 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]