The behaviour of read.csv().
On 02/12/2010 9:59 PM, Rolf Turner wrote:
On 3/12/2010, at 3:48 PM, David Scott wrote:
On 03/12/10 14:33, Duncan Murdoch wrote:
<SNIP>
I think the fill=TRUE option arrived about 10 years ago, in R 1.2.0. The comment in the NEWS file suggests it was in response to some strange csv file coming out of Excel. The real problem with the CSV format is that there really isn't a well defined standard for it. The first RFC about it was published in 2005, and it doesn't claim to be authoritative. Excel is kind of a standard, but it does some very weird things. (For example: enter the string 01 into a field. To keep the leading 0, you need to type it as '01. Save the file, read it back: goodbye 0. At least that's what a website I was just on says about Excel, and what OpenOffice does.) I've been burned so many times by storing data in .csv files, that I just avoid them whenever I can.
Absolutely agree with this Duncan. Playing around with .csv files is like playing with some sort of unstable explosive. I also avoid them as much as possible.
Where I work, everybody but me uses (yeuuccchhh!!!) Excel or SPSS. If we are to share data sets, *.csv files seem to be the most efficacious, if not the only, way to go.
I was going to suggest using DIF rather than CSV. It contains more internal information about the file (including the type of each entry), but has the disadvantage of being less readable, even though it is ascii. However, in putting together a little demo, I found a couple of bugs in the R implementation of read.DIF, and it looks as though it ignores the internal type information. Sigh. Duncan Murdoch
So far, we've had very few problems. The one that started off this thread is the only one I can think of that related to the *.csv format. At least *.csv files have the virtue of being ASCII files, whence if things go wrong it is at least possible to dig into them with a text editor and figure out just what the problem is. cheers, Rolf