Michael Chirico
2017-May-23 16:02 UTC
[Rd] Inconsistency in handling of numeric input with %d by sprintf
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> 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 <ecortens at 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 < >>> 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'; 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 at 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 at 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.Meys at Ugent.be >> ------------------------------- >> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >> > >[[alternative HTML version deleted]]
Evan Cortens
2017-May-23 16:32 UTC
[Rd] Inconsistency in handling of numeric input with %d by sprintf
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 <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. > > 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 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 <ecortens at 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 < >>>> 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'; 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 at 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 at 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.Meys at Ugent.be >>> ------------------------------- >>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >>> >> >> >[[alternative HTML version deleted]]
Tomas Kalibera
2017-May-25 13:06 UTC
[Rd] Inconsistency in handling of numeric input with %d by sprintf
Thanks, fixed in 72737 (R-devel). Best Tomas On 05/23/2017 06:32 PM, Evan Cortens wrote:> 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 <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. >> >> 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 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 <ecortens at 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 < >>>>> 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'; 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 at 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 at 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.Meys at Ugent.be >>>> ------------------------------- >>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >>>> >>> > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
Reasonably Related Threads
- Inconsistency in handling of numeric input with %d by sprintf
- Inconsistency in handling of numeric input with %d by sprintf
- Inconsistency in handling of numeric input with %d by sprintf
- Inconsistency in handling of numeric input with %d by sprintf
- Inconsistency in handling of numeric input with %d by sprintf