Re: [Rd] On read.csv and write.csv
> From: Simon Urbanek > By default there is no column name for a column of row names. > spreadsheets. Note that such CSV files can be read in R by > >read.csv(file = "", row.names = 1) AHA!! Many thanks. I see this clue is in ?write.table, though; I was looking for help on reading CSVs in ?read.csv etc. Thanks to all for your time answering this; much appreciated. S *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] On read.csv and write.csv
> the "unhelpful" column are the row names. They are considered an
> important part of a data frame and therefore the default (row.names =
> TRUE) is to not lose them (as there is no way back once you do). If you don't
> want to preserve the row names you can simply set row.names=FALSE.
Please run the reproducible example provided.
When you do, you will see that write.csv writes an unnecessary empty header
field ("") over the row names column. This makes the number of header fields
equal to the number of columns _including_ row names. That causes the original
row names to be read as data by read.csv, following the rule that the number of
header fields determines whether row names are present. read.csv accordingly
assumes that the former row names are unnamed data, calls the unnamed row names
column "X" (or X.1 etc if X exists) and then adds new, default, row names
_instead of the original row names written by write.csv_.
That's not helpful.
By contrast read.table correctly reads the first entry in each row as a row
name when the number of header fields is one less than the number of data
columns. write.table includes row names as row names _without a header field_,
so a file written with write.table is correctly formatted for read.table to
interpret the first data field as a row name.
I think it would be more sensible if write.csv did the same as write.table when
row.names=TRUE - as it is, by default.
***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If
you have received this message in error, please notify the sender
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com
and delete this message and any copies from your computer and network.
LGC Limited. Registered in England 2991879.
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] On read.csv and write.csv
Apologies if this is a well-worn question; I haven’t found it so far but
there's a lot of r-dev and I may have missed it in the archives. In the mean
time:
I've managed to avoid writing csv files with R for a couple of decades but
we're swopping data with a collaborator and I've tripped over an inconsistency
between read.csv and write.csv that seems less than helpful.
The default line number behaviour for read.csv is to assume that, when the
number of items in the first row is one less than the number in the second,
that the first column contains row names. write.csv, however, includes an empty
string ("") as the first header entry over row names when writing. On
rereading, the original row names are then treated as data with unknown name,
replaced by "X".
That means that, unlike read.table and write.table, something written with
write.csv is not read back correctly by read.csv .
Is that intentional?
And whether it is intentional or not, is it wise?
Example:
( D1 <- data.frame(A=letters[1:5], N=1:5, Y=rnorm(5) ) )
write.csv(D1, "temp.csv")
( D1w <- read.csv("temp.csv") )
# Note the unnecessary new X column ...
#Tidy up
unlink("temp.csv")
This differs from the parent .table defaults; write.table doesn’t add the extra
"" column label, so the object read back with read.table does not contain an
unwanted extra column.
Wouldn’t it be more sensible if write.csv() and read.csv() were consistent in
the same sense as read.table and write.table?
Or at least if there were a switch (as.read.csv=TRUE ?) to tell write.csv to
omit the initial "", or vice versa?
Currently using R version 4.1.0 on Windows, but this reproduces at least as far
back as 3.6
Steve E
***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If
you have received this message in error, please notify the sender
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com
and delete this message and any copies from your computer and network.
LGC Limited. Registered in England 2991879.
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mean
Note that in
> > quantile(c("1","2","3"),p=.5)
> Error in (1 - h) * qs[i] :
> argument non numérique pour un opérateur binaire
the default quantile type (7) does not work for non-numerics.
Quantile types 1 and 3 work as expected:
> quantile(c("1","2","3"),p=.5, type=1)
50%
"2"
> quantile(c("1","2","3"),p=.5, type=3)
50%
"2"
Steve E
***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If
you have received this message in error, please notify the sender
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com
and delete this message and any copies from your computer and network.
LGC Limited. Registered in England 2991879.
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ?Syntax wrong about `?`'s precedence ?
> From: William Dunlap [mailto:wdun...@tibco.com] > Precedence is a property of the parser and has nothing to do with the > semantics assigned to various symbols. Yes, but output depends on evaluation as well as precedence. Seeing different things wasn't an immediate surprise. Your own parse() examples are much clearer; thanks for that. S *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Underscores in package names
To throw a very small pennyworth into this debate, the metRology package I maintain uses mixed case to highlight R for that community when I'm talking about, or citing it. R takeup in that community is not yet high and the visible reminder seems to help. I'll obviously accept a consensus decision for some other case convention taken on sound technical grounds, but if this is essentially an aesthetic matter I'd prefer not to change it for someone else's idea of what looks pretty and what doesn’t. Steve Ellison > -Original Message- > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of neonira > Arinoem > Sent: 09 August 2019 20:39 > To: Ben Bolker > Cc: r-devel@r-project.org > Subject: Re: [Rd] Underscores in package names > > > Naming policies are always tricky. The one proposed by Hadley, as the one > proposed by Google, are usable but not optimal according to most common > needs, that are > > 1. Name a package > 2. Name a class > 3. Name a function > 4. Name a parameter of a function > 5. Name a variable > > ... *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R evolution suggestion request
> It is pure native R annotation, I mean à la java. I wish to have an @ > operator available a R language level to create/embed real code > annotations. Currently, the best I can get is to use a trick of hiding such > thing behind a comment. Neither good, not the right way, as comments are > comments, and annotations are annotations. They must be distinguished and > distinguish-able immediately, both for humans and code parsers. I can't comment on whether R can be extended in that way; that's R-core to answer. But @ is the slot extraction operator in S4 (see ?"@") so you'd need another operator symbol. But for faintly java-like annotation used for documentation and namespace management, you could look at the roxygen package; see https://cran.r-project.org/web/packages/roxygen2/vignettes/roxygen2.html S Ellison *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Unexpected email address change - and maybe a missing manual patch
Please forgive the unorthodox posting, but some marketing genius here has
decided I need a new corporate email address and has duly changed my outgoing
email without adequate notice to amend listserve subscriptions. The result is a
lot of unexpected bounces from R-help and R-devel. I'll try to fix that in
time, but more importantly a couple of you have been corresponding with me re a
proposed patch for a manual. I sent the patch a couple of days back, so if it
hasn;t arrived, it's probably got stuck behind a spam trap. If so, please let
me know, add the correct address to your spam filter and I'll try again ...
In the mean time I'll try to sort out the resulting listserve subscription mess.
Steve Ellison
LGC
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Checking R manual build
Is there a quick way of checking the R manuals built from the .texi files in
../doc/manual without building the rest of R?
Going from a vanilla checkout, some included files are missing (eg
version.texi) and created by the makefiles, so it looks like the complete make
script needs to be run at least once ... and then one has a number of
make-generated changes to one's R sources to worry about in any subsequent
diff.
Is the only route to export the svn copy, build from the exported copy and then
use texinfo to check the manual pages using the make-built includes and rules?
Steve Ellison
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Loose code in R package files
I'm sure i've seen the answer to this, but can't find it:
If there is executable code in an R package .R file that does not return a
function (that is, something like x - rnorm(5), outside any function body ),
what will actually happens at build and load time?
And (more importantly, so I can point a colleague to documented guidance on the
matter) is there somewhere in R's docs that says why this is not likely to be a
good idea and suggests the sort of things it is sensible - or not sensible - to
include in .R files?
S Ellison
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
