similar to: New strptime conversion specification for ordinal suffixes

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,

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

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

Follow-up (inline) on my comment about a potential issue in `[<-.Date`. On Mon, May 27, 2019 at 9:31 AM Michael Chirico <michaelchirico4 at gmail.com> wrote: > > Yes, thanks for following up on thread here. And thanks again for clearing things up, your email was a finger snap of clarity on the whole issue. > > I'll add that actually it was data.table's code at fault

I thought it would be good to summarize my thoughts, since I made a few hypotheses that turned out to be false. This isn't a bug in base R, in either rbind() or `[<-.Date`. To summarize the root cause: base::rbind.data.frame() calls `[<-` for each column of the data.frame, and there is no `[<-.IDate` method to ensure the replacement value is converted to integer. And, in fact,

On 4/24/25 00:18, Michael Chirico wrote: > In that case it seems like just erroring instead of returning invalid > pointers is a much friendlier option. Why give developers an unpinned > grenade to carry around? That would be too strict at this point. There is too much code around depending on that holding on to an invalid pointer (but not dereferencing it) is ok, and it is currently

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

Yes, thanks for following up on thread here. And thanks again for clearing things up, your email was a finger snap of clarity on the whole issue. I'll add that actually it was data.table's code at fault on the storage conversion -- note that if you use an arbitrary sub-class 'foo' with no methods defined, it'll stay integer. That's because [<- calls as.Date and then

On Sun, May 26, 2019 at 4:06 AM Michael Chirico <michaelchirico4 at gmail.com> wrote: > > Have finally managed to come up with a fix after checking out sys.calls() > from within the as.Date.IDate debugger, which shows something like: > > [[1]] rbind(DF, DF) > [[2]] rbind(deparse.level, ...) > [[3]] `[<-`(`*tmp*`, ri, value = 18042L) > [[4]] `[<-.Date`(`*tmp*`,

On Sun, May 26, 2019 at 6:47 AM Joshua Ulrich <josh.m.ulrich at gmail.com> wrote: > > On Sun, May 26, 2019 at 4:06 AM Michael Chirico > <michaelchirico4 at gmail.com> wrote: > > > > Have finally managed to come up with a fix after checking out sys.calls() > > from within the as.Date.IDate debugger, which shows something like: > > > > [[1]]

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

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 >

>>>>> Michael Chirico <michaelchirico4 at gmail.com> >>>>> on Tue, 27 Feb 2018 20:18:34 +0800 writes: Slightly amended 'Subject': (unimportant mistake: a dgeMatrix is *not* sparse) MM: modified to commented R code, slightly changed from your post: ## I am attempting to use the lars package with a sparse input feature matrix, ## but the following

[a bit unsure on if this is maybe better for r-package-devel] We recently added translations to messages at the R and C level to data.table. At the C level, we did _() wrapping for char arrays supplied to the following functions: error, warning, Rprintf, Error, and snprintf. This seemed OK but the use of snprintf specifically appears to have caused a crash on Windows:

I am attempting to use the lars package with a sparse input feature matrix, but the following fails: library(Matrix) library(lars) data(diabetes) attach(diabetes) x = as(as.matrix(as.data.frame(x)), 'dgCMatrix') lars(x, y, intercept = FALSE) Error in scale.default(x, FALSE, normx) : > > length of 'scale' must equal the number of columns of 'x' > > More

I happened to notice that this header file uses #import <Cocoa/Cocoa.h> This is the first time I came across the preprocessor directive #import; the first thing I found about it is this Q&A suggesting it's not portable nor standard C: https://stackoverflow.com/q/39280248/3576984 On the other hand, this exact invocation seems pretty common on GitHub

On Thu, 30 Jan 2025 13:07:31 -0800 Michael Chirico <michaelchirico4 at gmail.com> wrote: > There are at least dozens of other cases on CRAN [2],[3]. Some of these involve casting an int to Rboolean. Best case, the int is compared against NA_LOGICAL beforehand, avoiding any mistake (there's at least one like that). Worst case, NA_LOGICAL is not considered before the cast, so NA will

Full thread here: https://github.com/tidyverse/broom/issues/287 Reproducible example: is.object(freeny$y) # [1] TRUE attr(freeny$y, 'class') # [1] "ts" class(freeny$y) # [1] "ts" # ts attribute wiped by model.frame class(model.frame(y ~ ., data = freeny)$y) # [1] "numeric" attr(model.frame(y ~ ., data = freeny)$y, 'class') # NULL # but still:

Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was discussed, but it does look a bit unfortunate that usage patterns like c(NA, 0+1i) does not give complex NA

Thanks Simon, I didn't know that! That's definitely a compelling reason to leave the current default untouched and to eschew any finicky attempts to find back-up editors. Still, I think there is benefit from checking quickly that 'editor' exists at run-time in file.edit() -- the current failure mode is unusual (a shell error & R warning). Offering an R error would also