From maechler at stat.math.ethz.ch  Sat Dec  4 23:56:51 2004
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Sat Dec  4 23:56:54 2004
Subject: [Rd] write.table inconsistency (PR#7403)
In-Reply-To: <32h3r0h4hkapvs2htc73ga72712ten2bcf@4ax.com>
References: <20041204005526.3C298F18D@slim.kubism.ku.dk>
	<16817.45803.674748.804800@gargle.gargle.HOWL>
	<32h3r0h4hkapvs2htc73ga72712ten2bcf@4ax.com>
Message-ID: <16818.16563.400454.547294@gargle.gargle.HOWL>

>>>>> "Duncan" == Duncan Murdoch <murdoch@stats.uwo.ca>
>>>>>     on Sat, 04 Dec 2004 09:17:26 -0500 writes:

    Duncan> On Sat, 4 Dec 2004 13:51:55 +0100, Martin Maechler
    Duncan> <maechler@stat.math.ethz.ch> wrote:

    >>>>>>> "Duncan" == Duncan Murdoch <murdoch@stats.uwo.ca> on
    >>>>>>> Sat, 4 Dec 2004 01:55:26 +0100 (CET) writes:
    >>
    Duncan> There's an as.matrix() call in write.table that
    Duncan> means the formatting of numeric columns changes
    Duncan> depending on whether there are any non-numeric
    Duncan> columns in the table or not.
    >>  yes, I think I had seen this (a while ago in the source
    >> code) and then wondered if one shouldn't have used
    >> data.matrix() instead of as.matrix() - something I
    >> actually do advocate more generally, as "good programming
    >> style".  It also does solve the problem in the example
    >> here -- HOWEVER, the lines *before* as.matrix() have
    >> 
    >> ## as.matrix might turn integer or numeric columns into a
    >> complex matrix cmplx <- sapply(x, is.complex)
    >> if(any(cmplx) && !all(cmplx)) x[cmplx] <-
    >> lapply(x[cmplx], as.character) x <- as.matrix(x)
    >> 
    >> which makes you see that write.table(.) should also work
    >> when the data frame has complex variables {or some other
    >> kinds of non-numeric as you've said above} -- something
    >> which data.matrix() can't handle....  As soon as you have
    >> a complex or a character variable (together with others)
    >> in your data.frame, as.matrix() will have to return
    >> "character" and apply format() to the numeric variables,
    >> as well...
    >> 
    >> So, to make this consistent in your sense,
    >> i.e. formatting of a column shouldn't depend on the
    >> presence of other columns, we can't use as.matrix() nor
    >> data.matrix() but have to basically replicate an altered
    >> version of as.matrix inside write.table.
    >> 
    >> I propose to do this, but expose the altered version as
    >> something like as.charMatrix(.)
    >> 
    >> and replace the 4 lines {of code in write.table()} above
    >> by the single line as.charMatrix(x)

    Duncan> That sounds good.  Which version of the formatting
    Duncan> would you choose, leading spaces or not?  My
    Duncan> preference would be to leave off the leading spaces,

mine too, very strong preference, actually:

The behavior should be such that each column is formatted  
  ___ as if it was the only column of that data frame ___

    Duncan> in the belief that write.table is usually used for
    Duncan> data storage rather than data display, but it is
    Duncan> sometimes used for data display (e.g. in
    Duncan> utils::upgrade.packageStatus, which would not be
    Duncan> affected by your choice).


[Rd] write.table inconsistency (PR#7403)
Martin Maechler