search for: chirico

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

...39;%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_? Michael Chirico [[alternative HTML version deleted]]

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

...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, 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 fo...

...C program using the underlying strtol function (see data.table link for this program, and for full sessionInfo() of some environments with differing output). So, what is the correct output of strtoi("", base = 2L)? Is the cross-platform inconsistency to be expected/documentable? Michael Chirico [[alternative HTML version deleted]]

...ve allowed scale to work in this case)? (I'm aware that there's some import issues in lars, as the offending line to create normx *should* work, as is.numeric(sqrt(drop(rep(1, nrow(x)) %*% (x^2)))) is TRUE -- it's simply that lars doesn't import the appropriate S4 methods) Michael Chirico [[alternative HTML version deleted]]

...f. This seemed OK but the use of snprintf specifically appears to have caused a crash on Windows: https://github.com/Rdatatable/data.table/issues/4402 Is there any guidance against using gettext with snprintf, or perhaps guidance on which "outputters" *are* OK for translation? Michael Chirico [[alternative HTML version deleted]]

...he option apparently introduced here in 2012 & the ambiguity is immediate -- the commit mentions disable-long-double but builds enable-long-double. https://github.com/wch/r-source/commit/fb8e36f8be0aaf47a9c54c9effb219dae34f0e41 Could someone please help to clear the confusion? Thanks Michael Chirico [[alternative HTML version deleted]]

...n this issue will be in 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) &gt...

>>>>> Martin Maechler >>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes: >>>>> Michael Chirico >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes: >> Identified as root cause of a bug in data.table: >> https://github.com/Rdatatable/data.table/issues/3267 >> On my machine, strtoi("", base = 2L) produces NA_integer_ >> (which...

...bject. So the problem 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 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...

...10, NA)) is.object(DF$y) # [1] FALSE class(DF$y) = 'foo' is.object(DF$y) # [1] TRUE class(na.omit(DF)$y) # [1] "numeric" is.object(na.omit(DF)$y) # [1] FALSE That is, similarly presented with a classed object, na.omit strips the class *and* the OBJECT attribute. Thanks, Michael Chirico [[alternative HTML version deleted]]

...1i > as.complex("0+1i") [1] 0+1i > as.complex("1i") [1] NA Warning message: NAs introduced by coercion That warning seems wrong to me ... Mikael On 2023-11-07 6:00 am, r-devel-request at r-project.org wrote: >>>>>> Michael Chirico >>>>>> on Mon, 6 Nov 2023 23:18:40 -0800 writes: > > Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) > > should be, but rather, how I should read code like c(x, y) generally. Till > > now, I have thought of it like '...

...different from one of these? > 1i [1] 0+1i > str2lang("1i") [1] 0+1i > scan(textConnection("1i"), complex()) Read 1 item [1] 0+1i > > Mikael > On 2023-11-07 6:00 am, r-devel-request at r-project.org wrote: >>>>>>> Michael Chirico >>>>>>> on Mon, 6 Nov 2023 23:18:40 -0800 writes: >> > Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) >> > should be, but rather, how I should read code like c(x, y) generally. Till >> > now, I have thought of...

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

...es it won'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...

This link is referenced in ?timezones and appears to have been moved/removed. Is there a replacement? http://www.twinsun.com/tz/tz-link.htm [[alternative HTML version deleted]]

>>>>> Michael Chirico >>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes: > Identified as root cause of a bug in data.table: > https://github.com/Rdatatable/data.table/issues/3267 > On my machine, strtoi("", base = 2L) produces NA_integer_ > (which seems consisten...

...for Cocoa besides stuff like this page from 2001: http://cocoadevcentral.com/articles/000031.php Is this something that should be updated to use #include? Other packages appear to have done so, e.g. from GitHub: https://github.com/search?q=%22%23include+cocoa%2Fcocoa.h%22&type=code Michael Chirico [[alternative HTML version deleted]]