[Rd] Inconsistency in handling of numeric input with %d by sprintf

[Evan Cortens]

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