Inconsistency in handling of numeric input with %d by sprintf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Inconsistency in handling of numeric input with %d by sprintf

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inconsistency in handling of numeric input with %d by sprintf

Evan Cortens
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 <[hidden email]>
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]]
>
> ______________________________________________
> [hidden email] 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inconsistency in handling of numeric input with %d by sprintf

Joris FA Meys
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 <[hidden email]> 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 <
> [hidden email]>
> 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]]
> >
> > ______________________________________________
> > [hidden email] 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]]
>
> ______________________________________________
> [hidden email] 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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inconsistency in handling of numeric input with %d by sprintf

Michael Chirico
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 <[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]>
>> 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]]
>> >
>> > ______________________________________________
>> > [hidden email] 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]]
>>
>> ______________________________________________
>> [hidden email] 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>
> [hidden email]
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inconsistency in handling of numeric input with %d by sprintf

Michael 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 <[hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>>> [hidden email]>
>>> 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]]
>>> >
>>> > ______________________________________________
>>> > [hidden email] 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]]
>>>
>>> ______________________________________________
>>> [hidden email] 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>
>> [hidden email]
>> -------------------------------
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]
> 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 <
> [hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <
>>>> [hidden email]>
>>>> 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]]
>>>> >
>>>> > ______________________________________________
>>>> > [hidden email] 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]]
>>>>
>>>> ______________________________________________
>>>> [hidden email] 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>
>>> [hidden email]
>>> -------------------------------
>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>>
>>
>>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inconsistency in handling of numeric input with %d by sprintf

Tomas Kalibera
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 <[hidden email]
>> 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 <
>> [hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <
>>>>> [hidden email]>
>>>>> 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]]
>>>>>>
>>>>>> ______________________________________________
>>>>>> [hidden email] 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]]
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] 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>
>>>> [hidden email]
>>>> -------------------------------
>>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>>>
>>>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...