>>>>> "BDR" == Brian Ripley <[EMAIL PROTECTED]>
>>>>> on Tue, 22 Nov 2005 09:35:19 +0100 (CET) writes:
BDR> On Tue, 22 Nov 2005 [EMAIL PROTECTED] wrote:
>>>>>>> "KevinW" == Kevin Wright <[EMAIL PROTECTED]>
>>>>>>> on Mon, 21 Nov 2005 18:13:36 +0100 (CET) writes:
>>
KevinW> Full_Name: Kevin Wright
KevinW> Version: 2.2.0
KevinW> OS: Windows 2000
>> ^^^^^^^
>> this must be part of the problem
BDR> It is, and it is a known inconsistency with Linux (but I do not
consider
BDR> it to be a bug or `wrong behavior' or not `reasonable').
BDR> Windows always uses three digits for the exponent, e.g. E+001.
BDR> This results from adjusting the returned result to be more consistent
with
BDR> other platforms. (BTW, since width (sic) is a lower bound, it _is_
BDR> respected.) Even if the layout is not ideal, the results are at least
BDR> diff-able against those from other platforms.
yes, and that's good ("diff-able").
Now, after looking in the source (src/appl/strsignif.c),
I understand what you mean above: Because Windows libc's sprintf()
produces 3-digits exponents *and* because you amended the code
to change these back to 2 digits, the extraneous blank is a
consequence that one had to live with..
OTOH, the oldest R on Windows I have, "2.0.1 patched
(2004-11-27)" does *not* prepend the extra " " and gives the
same as on non-windows in some cases, i.e.,
> formatC(pi * 10^(-5:4))
[1] "3.142e-05" "0.0003142" "0.003142" "0.03142" "0.3142" "3.142"
[7] "31.42" "314.2" "3142" "3.142e+04"
Insofar, the svn r35148 (2005-08-04 18:17:00) change
did produce a backward incompatibility.
Which is why I confirmed Kevin that this was wrong behavior.
BDR> If Kevin (or anyone else) wants it done even more
BDR> consistently, he could contribute a patch.
yes, that would be useful.
Particularly, since for some cases formatC() *was* more
consistent (see above).
BDR> Now, we _have_ done that for print(), but it did not seem worth
BDR> it for formatC (especially as sprintf() is now widely
BDR> used and would also need to be made consistent).
I agree that sprintf should also be consistent, and I also agree
that for "real" programmers sprintf() is probably more useful
than formatC() which OTOH is easier to use for simple useRs.
BDR> (It also did not seem worth it
BDR> given how little credit is given for such work.)
KevinW> Submission from: (NULL) (170.54.58.4)
>>
KevinW> Apologies if my expectations (or reading of the man page) are
incorrect.
>>
KevinW> I seem unable to left-justify exponential format
KevinW> numbers. There appears to always be an extra space
KevinW> inserted to the left.
>>
KevinW> Using the example from the formatC help page:
>>
R> xx <- pi * 10^(-5:4)
>>
R> cbind(formatC(xx, wid = 9, flag = "-"))
KevinW> [,1]
KevinW> [1,] " 3.142e-05"
KevinW> [2,] "0.0003142"
KevinW> [3,] "0.003142 "
KevinW> [4,] "0.03142 "
KevinW> [5,] "0.3142 "
KevinW> [6,] "3.142 "
KevinW> [7,] "31.42 "
KevinW> [8,] "314.2 "
KevinW> [9,] "3142 "
KevinW> [10,] " 3.142e+04"
>>
>> which is also not obeying the 'wid' argument.
>>
>> I get something much more reasonable:
>>
>> [,1]
>> [1,] "3.142e-05"
>> [2,] "0.0003142"
>> [3,] "0.003142 "
>> [4,] "0.03142 "
>> [5,] "0.3142 "
>> [6,] "3.142 "
>> [7,] "31.42 "
>> [8,] "314.2 "
>> [9,] "3142 "
>> [10,] "3.142e+04"
>>
>> formatC uses your system's C library printf {that's where the
>> "C" comes from in 'formatC'} which seems to be
>> broken or at least not performing as we think it should.
>>
>> On a "Windows 2003 Server" I have access to, I see the same
>> wrong behavior as above.
>>
>> Martin Maechler, ETH Zurich
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
BDR> --
BDR> Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UK Fax: +44 1865 272595
BDR> ______________________________________________
BDR> R-devel@r-project.org mailing list
BDR> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
