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, Michael Chirico <michaelchiri...@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. > > On Tue, May 23, 2017 at 12:00 PM, Michael Chirico < > michaelchiri...@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 <jorism...@gmail.com> wrote: >> >>> 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 format '%d'; use format %f, %e, %g or %a for numeric objects >>> > sprintf("%d", as.numeric(c(1,NA))) >>> [1] "1" "NA" >>> >>> So the safest thing is indeed passing the right type, but the behaviour >>> is indeed confusing. I checked this on both Windows and Debian, and on both >>> systems I get the exact same response. >>> >>> Cheers >>> Joris >>> >>> On Tue, May 23, 2017 at 4:53 PM, Evan Cortens <ecort...@mtroyal.ca> >>> wrote: >>> >>>> 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.) 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 < >>>> michaelchiri...@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'; 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]] >>>> > >>>> > ______________________________________________ >>>> > R-devel@r-project.org mailing list >>>> > https://stat.ethz.ch/mailman/listinfo/r-devel >>>> > >>>> >>>> >>>> >>>> -- >>>> Evan Cortens, PhD >>>> Institutional Analyst - Office of Institutional Analysis >>>> Mount Royal University >>>> 403-440-6529 >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> >>> >>> -- >>> Joris Meys >>> Statistical consultant >>> >>> Ghent University >>> Faculty of Bioscience Engineering >>> Department of Mathematical Modelling, Statistics and Bio-Informatics >>> >>> tel : +32 (0)9 264 61 79 <+32%209%20264%2061%2079> >>> joris.m...@ugent.be >>> ------------------------------- >>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >>> >> >> > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
