[R-SIG-Mac] Unexpected behavior from sprintf()
dwinsemius at comcast.net
Wed Apr 25 00:20:37 CEST 2012
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:
>> and a subsequent discussion in the StackOverflow R chat room:
>> The issue is the output from the following code:
>> It appears that when this is run in OS X in either 2.14.2 or
>> 2.15.0, the
>> output is:
>>  "00001" "00002" "00003" "00004" "00005"
>> whereas when it is run on other platforms (I saw examples from
>> Windows versions and one user on Ubuntu, all using 2.15.0 I
>> believe) you
>>  " 1" " 2" " 3" " 4" " 5"
>> There was some uncertainty as to which behavior is "expected". Does
>> 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. 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
> In any case, R just passes a format like that to the C printf
> function. So if it's a bug, it's in the C run-time, not in R.
>> - Joran
>> [[alternative HTML version deleted]]
>> R-SIG-Mac mailing list
>> R-SIG-Mac at r-project.org
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
David Winsemius, MD
West Hartford, CT
More information about the R-SIG-Mac