On 12-04-24 5:12 PM, Simon Urbanek wrote:
On Apr 24, 2012, at 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".
The behavior of "%0s" is undefined -- this is documented both by R and POSIX
(arguably more clearly in the latter), so any behavior should be expected.
Does anyone
have any insight into which behavior is "correct" and whether this is a bug
or not?
It is not a bug. The formatting is done by the OS, so the results are always
OS-dependent -- since %0s is undefined, the OS can choose to interpret it any
way it wants.
Here's a slightly related question: If a single percent sign appears in
a string, not as the start of a conversion spec, is the behaviour
defined? For example, something taken from the R do_sprintf source in
one of the error messages:
"the '%*' constructed 'fmt2' exceeds maximum of %d"
There's certainly one decimal value to be displayed at the end, but is
the %* guaranteed to be interpreted literally? The R sprintf parser
gets confused by this one, but it's actually in the C code; is it a
legal C format string?
Duncan Murdoch
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
