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.
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
