[Rd] (PR#8337) formatC adds leading space -- on some Windoze

maechler@stat.math.ethz.ch maechler at stat.math.ethz.ch
Tue Nov 29 10:58:42 CET 2005


>>>>> "BDR" == Brian Ripley <ripley at stats.ox.ac.uk>
>>>>>     on Tue, 22 Nov 2005 09:35:19 +0100 (CET) writes:

    BDR> On Tue, 22 Nov 2005 maechler at stat.math.ethz.ch wrote:
    >>>>>>> "KevinW" == Kevin Wright <kwright68 at gmail.com>
    >>>>>>> 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 at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 
    >> 

    BDR> -- 
    BDR> Brian D. Ripley,                  ripley at stats.ox.ac.uk
    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 at r-project.org mailing list
    BDR> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list