[R-SIG-Mac] Unexpected behavior from sprintf()

[Duncan Murdoch]

On 12-04-24 6:20 PM, David Winsemius wrote:
>
> On Apr 24, 2012, at 6:07 PM, Duncan Murdoch wrote:
>
>> On 12-04-24 4:24 PM, Joran Elias wrote:
>>> I stumbled across this by accident from this StackOverflow question:
>>>
>>> http://stackoverflow.com/q/10300325/324364
>>>
>>> and a subsequent discussion in the StackOverflow R chat room:
>>>
>>> http://chat.stackoverflow.com/transcript/message/3431991#3431991
>>>
>>> The issue is the output from the following code:
>>>
>>> sprintf('%05s',as.character(1:5))
>>>
>>> It appears that when this is run in OS X in either 2.14.2 or
>>> 2.15.0, the
>>> output is:
>>>
>>> [1] "00001" "00002" "00003" "00004" "00005"
>>>
>>> whereas when it is run on other platforms (I saw examples from
>>> various
>>> Windows versions and one user on Ubuntu, all using 2.15.0 I
>>> believe) you
>>> get:
>>>
>>> [1] "    1" "    2" "    3" "    4" "    5"
>>>
>>> There was some uncertainty as to which behavior is "expected". Does
>>> anyone
>>> have any insight into which behavior is "correct" and whether this
>>> is a bug
>>> or not?
>>
>> I would say it's probably user-error:  the docs don't say what that
>> should do.   Numeric formats would pad with zeros, but I don't think
>> it says what would happen if you ask for zero padding on a string.
>
> The ?sprintf help page indicated that non-character R objects will get
> passed though `as.character` on their way to the system facility.

But those were character objects:  there was an explicit as.character(). 
  You get the same padding if you do

sprintf('%05s',letters[1:10])

i.e. 0 padding on OSX, blank padding on Windows.  (I haven't tried any 
others.)

Duncan Murdoch

In
> the case of a factor variable which has levels with numeric-coercible
> values, we Mac users get very sensible output. Likewise we get very
> sensible output from character vectors, and when a format of "05i" is
> used the fact that we get the numeric encoding for factors is likewise
> no surprise.
>