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

--

David.

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.



Duncan


- Joran

        [[alternative HTML version deleted]]

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

David Winsemius, MD
West Hartford, CT

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Reply via email to