search for: michaelchirico4

...tps://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 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 i...

...n my follow-up thread. Mike C On Mon, May 27, 2019, 10:25 PM Joshua Ulrich <josh.m.ulrich at gmail.com> wrote: > 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]] rbind(DF, DF) > > > [[2]] rbind(depars...

...d, 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, Michael Chirico <michaelchirico4 at gmail.com > wrote: > 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. &g...

...oblem exists, and can be fixed, in data.table. Best, Josh On Mon, May 27, 2019 at 9:34 AM Joshua Ulrich <josh.m.ulrich at gmail.com> wrote: > > 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 on the storage conversio...

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

...e vectors longer than 1 and their positioning vis-a-vis the > format string.) The safest thing is just to pass the right type. In this > case, sprintf('%d', as.integer(NA_real_)) works. > > Best, > > Evan > > On Fri, May 19, 2017 at 9:23 AM, Michael Chirico < > michaelchirico4 at gmail.com> > wrote: > > > Consider > > > > #as.numeric for emphasis > > sprintf('%d', as.numeric(1)) > > # [1] "1" > > > > vs. > > > > sprintf('%d', NA_real_) > > > > > Error in sprintf(&quot...

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 on the storage conversion -- note that if yo...

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

Debugging this issue: https://github.com/Rdatatable/data.table/issues/2008 We have custom class 'IDate' which inherits from 'Date' (it just forces integer storage for efficiency, hence, I). The concatenation done by rbind, however, breaks this and returns a double: library(data.table) DF = data.frame(date = as.IDate(Sys.Date())) storage.mode(rbind(DF, DF)$date) # [1]

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]] rbind(DF, DF) > > [[2]] rbind(deparse.level, ...) > > [[3]] `[&lt...

...real line". Also, notice that things like > Im(scan(text= "NA 0+1i", what=complex())) Read 2 items [1] NA 1 and > Im(as.complex(c(NA,"0+1i"))) [1] NA 1 but Martin probably thought more deeply about this? -pd > On 5 Nov 2023, at 18:41 , Michael Chirico <michaelchirico4 at gmail.com> wrote: > > This is another follow-up to the thread from September "Recent changes to > as.complex(NA_real_)". > > A test in data.table was broken by the changes for NA coercion to complex; > the breakage essentially comes from > > c(NA, 0+1i) &g...

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

...9;t. (My particular email had to do with the vectors longer than 1 and their positioning vis-a-vis the format string.) The safest thing is just to pass the right type. In this case, sprintf('%d', as.integer(NA_real_)) works. Best, Evan On Fri, May 19, 2017 at 9:23 AM, Michael Chirico <michaelchirico4 at gmail.com> wrote: > 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';...

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

...sitioning vis-a-vis the >> format string.) The safest thing is just to pass the right type. In this >> case, sprintf('%d', as.integer(NA_real_)) works. >> >> Best, >> >> Evan >> >> On Fri, May 19, 2017 at 9:23 AM, Michael Chirico < >> michaelchirico4 at gmail.com> >> wrote: >> >> > Consider >> > >> > #as.numeric for emphasis >> > sprintf('%d', as.numeric(1)) >> > # [1] "1" >> > >> > vs. >> > >> > sprintf('%d', NA_real_) >...

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

...od(.Generic), oldClass(x)) # <- restores 'IDate' class So we can fix our bug by defining a [<- class; the question that I still don't see answered in documentation or source code is, why/where is [<- called, exactly? Mike C On Sun, May 26, 2019 at 1:16 PM Michael Chirico <michaelchirico4 at gmail.com> wrote: > Debugging this issue: > > https://github.com/Rdatatable/data.table/issues/2008 > > We have custom class 'IDate' which inherits from 'Date' (it just forces > integer storage for efficiency, hence, I). > > The concatenation done by rb...

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:

This is another follow-up to the thread from September "Recent changes to as.complex(NA_real_)". A test in data.table was broken by the changes for NA coercion to complex; the breakage essentially comes from c(NA, 0+1i) # vs c(as.complex(NA), 0+1i) The former is the output we tested against; the latter is essentially (via coerceVector() in C) what's generated by our