Re: [R] help with read.table() function

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
(Moved from R-help).

This comes up often enough that I'm starting to think most functions
that take filename arguments should have file.choose() as the default
value.  Then one could do

read.table()

and have a dialog box pop up in Windows, or some other prompt for a
filename in other platforms.  Are there any obviously bad side effects
from a change like this?

Duncan Murdoch

On 1/29/2006 11:51 AM, Peter Dalgaard wrote:

> Romain Francois <[hidden email]> writes:
>
>> Le 29.01.2006 16:26, oliver wee a écrit :
>>
>>> hello, I have just started using R for doing a project
>>> in time series...
>>>
>>> unfortunately, I am having trouble using the
>>> read.table function for use in reading my data set.
>>>
>>> This is what I'm getting:
>>> I inputted:
>>> data <-
>>> read.table("D:/Oliver/Professional/Studies/Time Series
>>> Analysis/spdc2693.data", header = TRUE)
>>>
>>> I got:
>>> Error in file(file, "r") : unable to open connection
>>> In addition: Warning message:
>>> cannot open file 'D:/Oliver/Professional/Studies/Time
>>> Series Analysis/spdc2693.data', reason 'No such file
>>> or directory'
>>>
>>> as I am just a novice programmer, I really would
>>> appreciate help from you guys. Is there a need to
>>> setpath in R, like in java or something like that...
>>>
>>> I am using the windows version btw.
>>>
>>> I have also tried to put the file in the work
>>> directory of R, so that I only typed
>>> data <- read.table("spdc2693.data", header = TRUE)
>>> Again, it won't work, with the same error message.
>>>
>>> I would appreciate any help. thanks again.
>>>  
>>>
>> Hi, try :
>>
>> read.table(file.choose(), header=TRUE)
>>
>> and go to your file.
>> Also, you can look a ?setwd, ?getwd
>
> Right. Or just file.choose() and see what the OS thinks your file is
> really called. The most common causes for symptoms like that are
>
> (A) The file is "spcd2693.data"
> (B) There's an extra extension which ever helpful Windows decided to
> hide, as in "spdc2693.data.txt".
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Marc Schwartz (via MN)
I would argue against this.

If this were the default, that is requiring user interaction, it would
break a fair amount of code that I (and I am sure a lot of others have)
where automation is critical.

A lot of the issues seem to be user errors, file permission errors,
hidden extensions as is pointed out below and related issues. If there
is a legitimate bug in R resulting in these issues, then let's patch
that. However, I don't think that I can recall reproducible situations
where a bug in R is the root cause of these problems.

Best regards,

Marc Schwartz

On Sun, 2006-01-29 at 12:18 -0500, Duncan Murdoch wrote:

> (Moved from R-help).
>
> This comes up often enough that I'm starting to think most functions
> that take filename arguments should have file.choose() as the default
> value.  Then one could do
>
> read.table()
>
> and have a dialog box pop up in Windows, or some other prompt for a
> filename in other platforms.  Are there any obviously bad side effects
> from a change like this?
>
> Duncan Murdoch
>
> On 1/29/2006 11:51 AM, Peter Dalgaard wrote:
> > Romain Francois <[hidden email]> writes:
> >
> >> Le 29.01.2006 16:26, oliver wee a écrit :
> >>
> >>> hello, I have just started using R for doing a project
> >>> in time series...
> >>>
> >>> unfortunately, I am having trouble using the
> >>> read.table function for use in reading my data set.
> >>>
> >>> This is what I'm getting:
> >>> I inputted:
> >>> data <-
> >>> read.table("D:/Oliver/Professional/Studies/Time Series
> >>> Analysis/spdc2693.data", header = TRUE)
> >>>
> >>> I got:
> >>> Error in file(file, "r") : unable to open connection
> >>> In addition: Warning message:
> >>> cannot open file 'D:/Oliver/Professional/Studies/Time
> >>> Series Analysis/spdc2693.data', reason 'No such file
> >>> or directory'
> >>>
> >>> as I am just a novice programmer, I really would
> >>> appreciate help from you guys. Is there a need to
> >>> setpath in R, like in java or something like that...
> >>>
> >>> I am using the windows version btw.
> >>>
> >>> I have also tried to put the file in the work
> >>> directory of R, so that I only typed
> >>> data <- read.table("spdc2693.data", header = TRUE)
> >>> Again, it won't work, with the same error message.
> >>>
> >>> I would appreciate any help. thanks again.
> >>>  
> >>>
> >> Hi, try :
> >>
> >> read.table(file.choose(), header=TRUE)
> >>
> >> and go to your file.
> >> Also, you can look a ?setwd, ?getwd
> >
> > Right. Or just file.choose() and see what the OS thinks your file is
> > really called. The most common causes for symptoms like that are
> >
> > (A) The file is "spcd2693.data"
> > (B) There's an extra extension which ever helpful Windows decided to
> > hide, as in "spdc2693.data.txt".
> >
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
On 1/29/2006 12:55 PM, Marc Schwartz wrote:
> I would argue against this.
>
> If this were the default, that is requiring user interaction, it would
> break a fair amount of code that I (and I am sure a lot of others have)
> where automation is critical.

I don't see how this change could affect any code that currently works
-- maybe you misunderstood the proposal?  I'm just suggesting that the
args to functions that take input from files use file.choose() as a
default.  For example, read.table's arg list would change from

function (file, header = FALSE, ...

to

function (file = file.choose(), header = FALSE, ...

Currently a call like read.table() dies with an error message:

 > read.table()
Error in read.table() : argument "file" is missing, with no default

With this change we wouldn't get an error here.

>
> A lot of the issues seem to be user errors, file permission errors,
> hidden extensions as is pointed out below and related issues. If there
> is a legitimate bug in R resulting in these issues, then let's patch
> that. However, I don't think that I can recall reproducible situations
> where a bug in R is the root cause of these problems.

This isn't about fixing a bug, it's about making the user interface a
bit less error-prone.

Duncan Murdoch

>
> Best regards,
>
> Marc Schwartz
>
> On Sun, 2006-01-29 at 12:18 -0500, Duncan Murdoch wrote:
>> (Moved from R-help).
>>
>> This comes up often enough that I'm starting to think most functions
>> that take filename arguments should have file.choose() as the default
>> value.  Then one could do
>>
>> read.table()
>>
>> and have a dialog box pop up in Windows, or some other prompt for a
>> filename in other platforms.  Are there any obviously bad side effects
>> from a change like this?
>>
>> Duncan Murdoch
>>
>> On 1/29/2006 11:51 AM, Peter Dalgaard wrote:
>>> Romain Francois <[hidden email]> writes:
>>>
>>>> Le 29.01.2006 16:26, oliver wee a écrit :
>>>>
>>>>> hello, I have just started using R for doing a project
>>>>> in time series...
>>>>>
>>>>> unfortunately, I am having trouble using the
>>>>> read.table function for use in reading my data set.
>>>>>
>>>>> This is what I'm getting:
>>>>> I inputted:
>>>>> data <-
>>>>> read.table("D:/Oliver/Professional/Studies/Time Series
>>>>> Analysis/spdc2693.data", header = TRUE)
>>>>>
>>>>> I got:
>>>>> Error in file(file, "r") : unable to open connection
>>>>> In addition: Warning message:
>>>>> cannot open file 'D:/Oliver/Professional/Studies/Time
>>>>> Series Analysis/spdc2693.data', reason 'No such file
>>>>> or directory'
>>>>>
>>>>> as I am just a novice programmer, I really would
>>>>> appreciate help from you guys. Is there a need to
>>>>> setpath in R, like in java or something like that...
>>>>>
>>>>> I am using the windows version btw.
>>>>>
>>>>> I have also tried to put the file in the work
>>>>> directory of R, so that I only typed
>>>>> data <- read.table("spdc2693.data", header = TRUE)
>>>>> Again, it won't work, with the same error message.
>>>>>
>>>>> I would appreciate any help. thanks again.
>>>>>  
>>>>>
>>>> Hi, try :
>>>>
>>>> read.table(file.choose(), header=TRUE)
>>>>
>>>> and go to your file.
>>>> Also, you can look a ?setwd, ?getwd
>>> Right. Or just file.choose() and see what the OS thinks your file is
>>> really called. The most common causes for symptoms like that are
>>>
>>> (A) The file is "spcd2693.data"
>>> (B) There's an extra extension which ever helpful Windows decided to
>>> hide, as in "spdc2693.data.txt".
>>>
>>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Brian Ripley
In reply to this post by Marc Schwartz (via MN)
On Sun, 29 Jan 2006, Marc Schwartz wrote:

> I would argue against this.
>
> If this were the default, that is requiring user interaction, it would
> break a fair amount of code that I (and I am sure a lot of others have)
> where automation is critical.

I don't see how.  The current default is

> read.table()
Error in read.table() : argument "file" is missing, with no default

so the only change is that the default might do something useful.

Nor do I see the change would help, as the same people would still use a
character string for 'file' and not omit the argument.  (It seems very
unlikely that they would read any documentation that suggested things had
changed.)

The same issue could be made over scan(), where the current default is
useful.

> A lot of the issues seem to be user errors, file permission errors,
> hidden extensions as is pointed out below and related issues. If there
> is a legitimate bug in R resulting in these issues, then let's patch
> that. However, I don't think that I can recall reproducible situations
> where a bug in R is the root cause of these problems.

Nor I.

Note that file.choose does not protect you against file permission issues
(actually, on a command-line Unix-alike it does nothing much useful at
all):

> readLines(file.choose())
Enter file name: errs.txt
Error in file(con, "r") : unable to open connection
In addition: Warning message:
cannot open file 'errs.txt', reason 'Permission denied'

but

> file.show(file.choose())
says

NO FILE errs.txt

which is not a good idea (and I will improve).

So this would really only have any effect on GUI platforms, for people who
read the documentation.


> Best regards,
>
> Marc Schwartz
>
> On Sun, 2006-01-29 at 12:18 -0500, Duncan Murdoch wrote:
>> (Moved from R-help).
>>
>> This comes up often enough that I'm starting to think most functions
>> that take filename arguments should have file.choose() as the default
>> value.  Then one could do
>>
>> read.table()
>>
>> and have a dialog box pop up in Windows, or some other prompt for a
>> filename in other platforms.  Are there any obviously bad side effects
>> from a change like this?
>>
>> Duncan Murdoch
>>
>> On 1/29/2006 11:51 AM, Peter Dalgaard wrote:
>>> Romain Francois <[hidden email]> writes:
>>>
>>>> Le 29.01.2006 16:26, oliver wee a écrit :
>>>>
>>>>> hello, I have just started using R for doing a project
>>>>> in time series...
>>>>>
>>>>> unfortunately, I am having trouble using the
>>>>> read.table function for use in reading my data set.
>>>>>
>>>>> This is what I'm getting:
>>>>> I inputted:
>>>>> data <-
>>>>> read.table("D:/Oliver/Professional/Studies/Time Series
>>>>> Analysis/spdc2693.data", header = TRUE)
>>>>>
>>>>> I got:
>>>>> Error in file(file, "r") : unable to open connection
>>>>> In addition: Warning message:
>>>>> cannot open file 'D:/Oliver/Professional/Studies/Time
>>>>> Series Analysis/spdc2693.data', reason 'No such file
>>>>> or directory'
>>>>>
>>>>> as I am just a novice programmer, I really would
>>>>> appreciate help from you guys. Is there a need to
>>>>> setpath in R, like in java or something like that...
>>>>>
>>>>> I am using the windows version btw.
>>>>>
>>>>> I have also tried to put the file in the work
>>>>> directory of R, so that I only typed
>>>>> data <- read.table("spdc2693.data", header = TRUE)
>>>>> Again, it won't work, with the same error message.
>>>>>
>>>>> I would appreciate any help. thanks again.
>>>>>
>>>>>
>>>> Hi, try :
>>>>
>>>> read.table(file.choose(), header=TRUE)
>>>>
>>>> and go to your file.
>>>> Also, you can look a ?setwd, ?getwd
>>>
>>> Right. Or just file.choose() and see what the OS thinks your file is
>>> really called. The most common causes for symptoms like that are
>>>
>>> (A) The file is "spcd2693.data"
>>> (B) There's an extra extension which ever helpful Windows decided to
>>> hide, as in "spdc2693.data.txt".
>>>
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Marc Schwartz (via MN)
In reply to this post by Duncan Murdoch
Duncan,

OK. I mis-understood the proposal. My error.

Thanks for the clarification.

Marc

On Sun, 2006-01-29 at 13:08 -0500, Duncan Murdoch wrote:

> On 1/29/2006 12:55 PM, Marc Schwartz wrote:
> > I would argue against this.
> >
> > If this were the default, that is requiring user interaction, it would
> > break a fair amount of code that I (and I am sure a lot of others have)
> > where automation is critical.
>
> I don't see how this change could affect any code that currently works
> -- maybe you misunderstood the proposal?  I'm just suggesting that the
> args to functions that take input from files use file.choose() as a
> default.  For example, read.table's arg list would change from
>
> function (file, header = FALSE, ...
>
> to
>
> function (file = file.choose(), header = FALSE, ...
>
> Currently a call like read.table() dies with an error message:
>
>  > read.table()
> Error in read.table() : argument "file" is missing, with no default
>
> With this change we wouldn't get an error here.
>
> >
> > A lot of the issues seem to be user errors, file permission errors,
> > hidden extensions as is pointed out below and related issues. If there
> > is a legitimate bug in R resulting in these issues, then let's patch
> > that. However, I don't think that I can recall reproducible situations
> > where a bug in R is the root cause of these problems.
>
> This isn't about fixing a bug, it's about making the user interface a
> bit less error-prone.
>
> Duncan Murdoch
>
> >
> > Best regards,
> >
> > Marc Schwartz
> >
> > On Sun, 2006-01-29 at 12:18 -0500, Duncan Murdoch wrote:
> >> (Moved from R-help).
> >>
> >> This comes up often enough that I'm starting to think most functions
> >> that take filename arguments should have file.choose() as the default
> >> value.  Then one could do
> >>
> >> read.table()
> >>
> >> and have a dialog box pop up in Windows, or some other prompt for a
> >> filename in other platforms.  Are there any obviously bad side effects
> >> from a change like this?
> >>
> >> Duncan Murdoch
> >>
> >> On 1/29/2006 11:51 AM, Peter Dalgaard wrote:
> >>> Romain Francois <[hidden email]> writes:
> >>>
> >>>> Le 29.01.2006 16:26, oliver wee a écrit :
> >>>>
> >>>>> hello, I have just started using R for doing a project
> >>>>> in time series...
> >>>>>
> >>>>> unfortunately, I am having trouble using the
> >>>>> read.table function for use in reading my data set.
> >>>>>
> >>>>> This is what I'm getting:
> >>>>> I inputted:
> >>>>> data <-
> >>>>> read.table("D:/Oliver/Professional/Studies/Time Series
> >>>>> Analysis/spdc2693.data", header = TRUE)
> >>>>>
> >>>>> I got:
> >>>>> Error in file(file, "r") : unable to open connection
> >>>>> In addition: Warning message:
> >>>>> cannot open file 'D:/Oliver/Professional/Studies/Time
> >>>>> Series Analysis/spdc2693.data', reason 'No such file
> >>>>> or directory'
> >>>>>
> >>>>> as I am just a novice programmer, I really would
> >>>>> appreciate help from you guys. Is there a need to
> >>>>> setpath in R, like in java or something like that...
> >>>>>
> >>>>> I am using the windows version btw.
> >>>>>
> >>>>> I have also tried to put the file in the work
> >>>>> directory of R, so that I only typed
> >>>>> data <- read.table("spdc2693.data", header = TRUE)
> >>>>> Again, it won't work, with the same error message.
> >>>>>
> >>>>> I would appreciate any help. thanks again.
> >>>>>  
> >>>>>
> >>>> Hi, try :
> >>>>
> >>>> read.table(file.choose(), header=TRUE)
> >>>>
> >>>> and go to your file.
> >>>> Also, you can look a ?setwd, ?getwd
> >>> Right. Or just file.choose() and see what the OS thinks your file is
> >>> really called. The most common causes for symptoms like that are
> >>>
> >>> (A) The file is "spcd2693.data"
> >>> (B) There's an extra extension which ever helpful Windows decided to
> >>> hide, as in "spdc2693.data.txt".
> >>>
> >>>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
In reply to this post by Brian Ripley
On 1/29/2006 1:29 PM, Prof Brian Ripley wrote:

> On Sun, 29 Jan 2006, Marc Schwartz wrote:
>
>> I would argue against this.
>>
>> If this were the default, that is requiring user interaction, it would
>> break a fair amount of code that I (and I am sure a lot of others have)
>> where automation is critical.
>
> I don't see how.  The current default is
>
>> read.table()
> Error in read.table() : argument "file" is missing, with no default
>
> so the only change is that the default might do something useful.
>
> Nor do I see the change would help, as the same people would still use a
> character string for 'file' and not omit the argument.  (It seems very
> unlikely that they would read any documentation that suggested things had
> changed.)

No, but people teaching new users (or answering R-help questions) would
have a simpler answer:  just use read.table().

> The same issue could be made over scan(), where the current default is
> useful.

scan() is very useful for small reads, and rarely needed for reading big
formatted files, so I wouldn't propose to change it.  The inconsistency
with read.table would be unfortunate, but no worse than the current one.

>> A lot of the issues seem to be user errors, file permission errors,
>> hidden extensions as is pointed out below and related issues. If there
>> is a legitimate bug in R resulting in these issues, then let's patch
>> that. However, I don't think that I can recall reproducible situations
>> where a bug in R is the root cause of these problems.
>
> Nor I.
>
> Note that file.choose does not protect you against file permission issues
> (actually, on a command-line Unix-alike it does nothing much useful at
> all):
>
>> readLines(file.choose())
> Enter file name: errs.txt

No, it's not helpful here, but again it makes things no worse, and
there's always the possibility that someone would improve file.choose().

Duncan Murdoch

> Error in file(con, "r") : unable to open connection
> In addition: Warning message:
> cannot open file 'errs.txt', reason 'Permission denied'
>
> but
>
>> file.show(file.choose())
> says
>
> NO FILE errs.txt
>
> which is not a good idea (and I will improve).
>
> So this would really only have any effect on GUI platforms, for people who
> read the documentation.
>
>
>> Best regards,
>>
>> Marc Schwartz
>>
>> On Sun, 2006-01-29 at 12:18 -0500, Duncan Murdoch wrote:
>>> (Moved from R-help).
>>>
>>> This comes up often enough that I'm starting to think most functions
>>> that take filename arguments should have file.choose() as the default
>>> value.  Then one could do
>>>
>>> read.table()
>>>
>>> and have a dialog box pop up in Windows, or some other prompt for a
>>> filename in other platforms.  Are there any obviously bad side effects
>>> from a change like this?
>>>
>>> Duncan Murdoch
>>>
>>> On 1/29/2006 11:51 AM, Peter Dalgaard wrote:
>>>> Romain Francois <[hidden email]> writes:
>>>>
>>>>> Le 29.01.2006 16:26, oliver wee a écrit :
>>>>>
>>>>>> hello, I have just started using R for doing a project
>>>>>> in time series...
>>>>>>
>>>>>> unfortunately, I am having trouble using the
>>>>>> read.table function for use in reading my data set.
>>>>>>
>>>>>> This is what I'm getting:
>>>>>> I inputted:
>>>>>> data <-
>>>>>> read.table("D:/Oliver/Professional/Studies/Time Series
>>>>>> Analysis/spdc2693.data", header = TRUE)
>>>>>>
>>>>>> I got:
>>>>>> Error in file(file, "r") : unable to open connection
>>>>>> In addition: Warning message:
>>>>>> cannot open file 'D:/Oliver/Professional/Studies/Time
>>>>>> Series Analysis/spdc2693.data', reason 'No such file
>>>>>> or directory'
>>>>>>
>>>>>> as I am just a novice programmer, I really would
>>>>>> appreciate help from you guys. Is there a need to
>>>>>> setpath in R, like in java or something like that...
>>>>>>
>>>>>> I am using the windows version btw.
>>>>>>
>>>>>> I have also tried to put the file in the work
>>>>>> directory of R, so that I only typed
>>>>>> data <- read.table("spdc2693.data", header = TRUE)
>>>>>> Again, it won't work, with the same error message.
>>>>>>
>>>>>> I would appreciate any help. thanks again.
>>>>>>
>>>>>>
>>>>> Hi, try :
>>>>>
>>>>> read.table(file.choose(), header=TRUE)
>>>>>
>>>>> and go to your file.
>>>>> Also, you can look a ?setwd, ?getwd
>>>> Right. Or just file.choose() and see what the OS thinks your file is
>>>> really called. The most common causes for symptoms like that are
>>>>
>>>> (A) The file is "spcd2693.data"
>>>> (B) There's an extra extension which ever helpful Windows decided to
>>>> hide, as in "spdc2693.data.txt".
>>>>
>>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
In reply to this post by Duncan Murdoch
On 1/29/2006 1:24 PM, Gabor Grothendieck wrote:
 > Normally one expects stdin to be the default on command line
 > programs and something like file.choose to be the default on GUI
 > programs and this would break that expectation.

We don't currently meet that expectation, so I don't think it would make
things any worse.  As I mentioned to Brian, I wouldn't change the
default for scan() (which is stdin everywhere).  I haven't done a
complete survey yet, but after looking at a few, I think the rules I
would use are these:

  - the function should use the filename argument to find an existing file
  - it should not already have a default
  - it should be something that would commonly be used interactively

Ones I would change which currently give an error with no filename:

read.table() and friends
dget()
read.dcf()
source()
read.ftable()
tkpager()
md5sum()
Rd_parse()

Ones I probably wouldn't touch:

unz()
file.create(), etc.
file() gives a temporary file for writing
dput(), write.dcf() write to the console
dev2bitmap(), bitmap()
file.show() - which might be called with an empty file list, which we
should treat as a no-op

Ones I'm not sure about right now, because they're relatively obscure:

sys.source()
shell.exec()

Duncan Murdoch
 >
 > If there were a GUI version of read.table then that would reasonbly
 > have file.choose as the default.
 >
 > On 1/29/06, Duncan Murdoch <[hidden email]> wrote:
 >> On 1/29/2006 11:28 AM, oliver wee wrote:
 >>> hi,
 >>>
 >>> Sorry again to bother you, but I got the file.choose()
 >>> to work. Thanks for the help there.
 >>>
 >>> Unfortunately I encountered a new problem. After I
 >>> selected the data, I got this error message:
 >>>
 >>> Error in scan(file = file, what = what, sep = sep,
 >>> quote = quote, dec = dec,  :
 >>>         line 1 did not have 11 elements
 >>> In addition: Warning message:
 >>> incomplete final line found by readTableHeader on
 >>> 'D:\Oliver\Professional\Studies\Time Series
 >>> Analysis\spdc2693.data.txt'
 >>>
 >>> my time series data looks like this...
 >>>
 >>> ------------
 >>> Standard and Poor's 500 Index closing values from 1926
 >>> to 1993.
 >>>
 >>>   Date       Index
 >>>   260101     12.76
 >>>   260108     12.78
 >>>   260115     12.52
 >>>   260122     12.45
 >>>   260129     12.74
 >>>   260205     12.87
 >>>   260212     12.87
 >>>   260219     12.74
 >>>   260226     12.18
 >>>   260305     11.99
 >>>   260312     12.15
 >>>   260319     11.64
 >>>   260326     11.46
 >>> ...
 >>> (and so on)
 >>> ----------
 >>>
 >>> Should I insert additional attributes besides header =
 >>> TRUE?
 >> Yes, you need to tell it to skip over the lines of the comment at the
 >> start of the file.  That looks like 3 lines (including the blank line),
 >> so add skip=3 to your read.table call.
 >>
 >> Duncan Murdoch
 >>
 >>> thanks.
 >>>
 >>>
 >>> --- Duncan Murdoch <[hidden email]> wrote:
 >>>
 >>>> On 1/29/2006 10:26 AM, oliver wee wrote:
 >>>>> hello, I have just started using R for doing a
 >>>> project
 >>>>> in time series...
 >>>>>
 >>>>> unfortunately, I am having trouble using the
 >>>>> read.table function for use in reading my data
 >>>> set.
 >>>>> This is what I'm getting:
 >>>>> I inputted:
 >>>>> data <-
 >>>>> read.table("D:/Oliver/Professional/Studies/Time
 >>>> Series
 >>>>> Analysis/spdc2693.data", header = TRUE)
 >>>> Generally it's easier to use the dialogs to specify
 >>>> the filename, e.g.
 >>>>
 >>>> read.table(file.choose(), header=TRUE)
 >>>>
 >>>> Then you shouldn't get the "no such file" message.
 >>>> If you do, you
 >>>> should check whether other programs (e.g. notepad)
 >>>> can open the file.
 >>>> Maybe you don't have read permission?
 >>>>
 >>>> Duncan Murdoch
 >>>>
 >>>>> I got:
 >>>>> Error in file(file, "r") : unable to open
 >>>> connection
 >>>>> In addition: Warning message:
 >>>>> cannot open file
 >>>> 'D:/Oliver/Professional/Studies/Time
 >>>>> Series Analysis/spdc2693.data', reason 'No such
 >>>> file
 >>>>> or directory'
 >>>>>
 >>>>> as I am just a novice programmer, I really would
 >>>>> appreciate help from you guys. Is there a need to
 >>>>> setpath in R, like in java or something like
 >>>> that...
 >>>>> I am using the windows version btw.
 >>>>>
 >>>>> I have also tried to put the file in the work
 >>>>> directory of R, so that I only typed
 >>>>> data <- read.table("spdc2693.data", header = TRUE)
 >>>>> Again, it won't work, with the same error message.
 >>>>>
 >>>>> I would appreciate any help. thanks again.
 >>>>>
 >>>>> ______________________________________________
 >>>>> [hidden email] mailing list
 >>>>> https://stat.ethz.ch/mailman/listinfo/r-help
 >>>>> PLEASE do read the posting guide!
 >>>> http://www.R-project.org/posting-guide.html
 >>>>
 >>>>
 >>>
 >>> __________________________________________________
 >>> Do You Yahoo!?
 >>> Tired of spam?  Yahoo! Mail has the best spam protection around
 >>> http://mail.yahoo.com
 >> ______________________________________________
 >> [hidden email] mailing list
 >> https://stat.ethz.ch/mailman/listinfo/r-help
 >> PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
 >>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Gabor Grothendieck
On 1/29/06, Duncan Murdoch <[hidden email]> wrote:
> On 1/29/2006 1:24 PM, Gabor Grothendieck wrote:
>  > Normally one expects stdin to be the default on command line
>  > programs and something like file.choose to be the default on GUI
>  > programs and this would break that expectation.
>
> We don't currently meet that expectation, so I don't think it would make
> things any worse.  As I mentioned to Brian, I wouldn't change the

II don't think you understood my point.  This is how most software works,
IN GENERAL, so R should be expected to work that way
too.   I don't think not having a default is so bad but having the wrong
default that breaks the stereotype that one expects in all software
is bad.

What could be done is to add something about file.choose to the
error message that one gets when one does read.table("myfile")
and it can't find "myfile".

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
On 1/29/2006 5:20 PM, Gabor Grothendieck wrote:

> On 1/29/06, Duncan Murdoch <[hidden email]> wrote:
>> On 1/29/2006 1:24 PM, Gabor Grothendieck wrote:
>>  > Normally one expects stdin to be the default on command line
>>  > programs and something like file.choose to be the default on GUI
>>  > programs and this would break that expectation.
>>
>> We don't currently meet that expectation, so I don't think it would make
>> things any worse.  As I mentioned to Brian, I wouldn't change the
>
> II don't think you understood my point.  This is how most software works,
> IN GENERAL, so R should be expected to work that way
> too.  

I think I understood that, but my point is that R doesn't act that way
now, and this change won't make the situation worse.

 >I don't think not having a default is so bad but having the wrong
> default that breaks the stereotype that one expects in all software
> is bad.

I don't follow your argument.  Why is it better to say

Error in read.table() : argument "file" is missing, with no default

than it would be to ask the user which file to read?  The first is
unexpected in both of the situations you described, while the second is
only unexpected in a command line program.

Consistency is a good thing, but there are a number of choices of what
to be consistent with:

  - other similar functions in R (but they are inconsistent)
  - previous versions of R (which is why I wouldn't change scan())
  - other software a user would be familiar with (which is why
file.choose() is a good idea in a GUI, but not in a command line program).

> What could be done is to add something about file.choose to the
> error message that one gets when one does read.table("myfile")
> and it can't find "myfile".

Currently our error messages explain what went wrong, they generally
don't try to suggest alternative approaches (though a few do, e.g.
help("dfdsfs")).  There are a lot of reasons read.table() could fail,
and I think it would be very hard to get a good automatic rule on when
file.choose() was the appropriate alternative.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Gabor Grothendieck
On 1/29/06, Duncan Murdoch <[hidden email]> wrote:

> On 1/29/2006 5:20 PM, Gabor Grothendieck wrote:
> > On 1/29/06, Duncan Murdoch <[hidden email]> wrote:
> >> On 1/29/2006 1:24 PM, Gabor Grothendieck wrote:
> >>  > Normally one expects stdin to be the default on command line
> >>  > programs and something like file.choose to be the default on GUI
> >>  > programs and this would break that expectation.
> >>
> >> We don't currently meet that expectation, so I don't think it would make
> >> things any worse.  As I mentioned to Brian, I wouldn't change the
> >
> > II don't think you understood my point.  This is how most software works,
> > IN GENERAL, so R should be expected to work that way
> > too.
>
> I think I understood that, but my point is that R doesn't act that way
> now, and this change won't make the situation worse.
>
>  >I don't think not having a default is so bad but having the wrong
> > default that breaks the stereotype that one expects in all software
> > is bad.
>
> I don't follow your argument.  Why is it better to say
>
> Error in read.table() : argument "file" is missing, with no default

Because that does not mix conventions.

>
> than it would be to ask the user which file to read?  The first is
> unexpected in both of the situations you described, while the second is
> only unexpected in a command line program.

Because its conventional that stdin is the default.  Even in R someone
must have realized that since that is the default for scan.


>
> Consistency is a good thing, but there are a number of choices of what
> to be consistent with:
>
>  - other similar functions in R (but they are inconsistent)
>  - previous versions of R (which is why I wouldn't change scan())
>  - other software a user would be familiar with (which is why
> file.choose() is a good idea in a GUI, but not in a command line program).
>
> > What could be done is to add something about file.choose to the
> > error message that one gets when one does read.table("myfile")
> > and it can't find "myfile".
>
> Currently our error messages explain what went wrong, they generally
> don't try to suggest alternative approaches (though a few do, e.g.
> help("dfdsfs")).  There are a lot of reasons read.table() could fail,
> and I think it would be very hard to get a good automatic rule on when
> file.choose() was the appropriate alternative.

I wasn't suggesting an automatic solution but I think it could be helpful
if the error message pointed out the existence of file.choose.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Martin Maechler
In reply to this post by Duncan Murdoch
>>>>> "Duncan" == Duncan Murdoch <[hidden email]>
>>>>>     on Sun, 29 Jan 2006 16:35:50 -0500 writes:

    Duncan> On 1/29/2006 1:29 PM, Prof Brian Ripley wrote:
    >> On Sun, 29 Jan 2006, Marc Schwartz wrote:
    >>
    >>> I would argue against this.
    >>>
    >>> If this were the default, that is requiring user
    >>> interaction, it would break a fair amount of code that I
    >>> (and I am sure a lot of others have) where automation is
    >>> critical.

    >>  I don't see how.  The current default is
    >>
    >>> read.table()
    >> Error in read.table() : argument "file" is missing, with
    >> no default
    >>
    >> so the only change is that the default might do something
    >> useful.
    >>
    >> Nor do I see the change would help, as the same people
    >> would still use a character string for 'file' and not
    >> omit the argument.  (It seems very unlikely that they
    >> would read any documentation that suggested things had
    >> changed.)

    Duncan> No, but people teaching new users (or answering
    Duncan> R-help questions) would have a simpler answer: just
    Duncan> use read.table().

but I am not sure that people teaching R should advocate such a
read.table;  
I they did, the new R users would get the concept that this is
the way how to use R.
I still think R should eventually be used for "Programming with Data"
rather than a GUI for ``clicking results together''.
Hence users should be taught (in the 2nd or 3rd part, not the
1st one of their introduction to R)
to work with R scripts, writing functions etc.

And similar to Marc, I would never want default behavior to
start up a GUI elements: It is also much more error-prone; just
consider the  "choose CRAN mirror" GUI that we had recently
introduced, and the many questions and "bug" reports it produced.

I know that I am biased in my views here;
but I strongly advocate the  "useRs becoming programmeRs" theme
and hence rather keep R consistent as a programming language,
partly agreeing with Gabor here.

    >> The same issue could be made over scan(), where the
    >> current default is useful.

    Duncan> scan() is very useful for small reads, and rarely
    Duncan> needed for reading big formatted files,

{people might disagree with this; given scan() is more efficient
 for large files;  but that's not really the topic here.}

    Duncan> so I wouldn't propose to change it.  
good.

    Duncan> The inconsistency
    Duncan> with read.table would be unfortunate, but no worse
    Duncan> than the current one.


    >>> A lot of the issues seem to be user errors, file
    >>> permission errors, hidden extensions as is pointed out
    >>> below and related issues. If there is a legitimate bug
    >>> in R resulting in these issues, then let's patch
    >>> that. However, I don't think that I can recall
    >>> reproducible situations where a bug in R is the root
    >>> cause of these problems.

    >>  Nor I.
    >>
    >> Note that file.choose does not protect you against file
    >> permission issues (actually, on a command-line Unix-alike
    >> it does nothing much useful at all):
    >>
    >>> readLines(file.choose())
    >> Enter file name: errs.txt

    Duncan> No, it's not helpful here, but again it makes things
    Duncan> no worse, and there's always the possibility that
    Duncan> someone would improve file.choose().

I strongly prefer the current usage

  read.table(file.choose(), ....)

which implicitly ``explains'' how the file name is chosen to a
new default
  read.table( .....)

I'd like basic R functions not to call menu(), GUI... parts
unless it's really the main task of that function.

Martin


   .............................
   .............................

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Duncan Murdoch
On 1/30/2006 4:16 AM, Martin Maechler wrote:

>>>>>> "Duncan" == Duncan Murdoch <[hidden email]>
>>>>>>     on Sun, 29 Jan 2006 16:35:50 -0500 writes:
>
>     Duncan> On 1/29/2006 1:29 PM, Prof Brian Ripley wrote:
>     >> On Sun, 29 Jan 2006, Marc Schwartz wrote:
>     >>
>     >>> I would argue against this.
>     >>>
>     >>> If this were the default, that is requiring user
>     >>> interaction, it would break a fair amount of code that I
>     >>> (and I am sure a lot of others have) where automation is
>     >>> critical.
>
>     >>  I don't see how.  The current default is
>     >>
>     >>> read.table()
>     >> Error in read.table() : argument "file" is missing, with
>     >> no default
>     >>
>     >> so the only change is that the default might do something
>     >> useful.
>     >>
>     >> Nor do I see the change would help, as the same people
>     >> would still use a character string for 'file' and not
>     >> omit the argument.  (It seems very unlikely that they
>     >> would read any documentation that suggested things had
>     >> changed.)
>
>     Duncan> No, but people teaching new users (or answering
>     Duncan> R-help questions) would have a simpler answer: just
>     Duncan> use read.table().
>
> but I am not sure that people teaching R should advocate such a
> read.table;  
> I they did, the new R users would get the concept that this is
> the way how to use R.

I'd say "a way to use R", and I think teachers *should* present such a
use.  It insulates users from uninteresting details, just as now it's
probably good to advocate using file.choose() rather than explaining
paths and escape characters before beginners can do anything with data.
Later on they'll need to learn those things, but not from the beginning.

> I still think R should eventually be used for "Programming with Data"
> rather than a GUI for ``clicking results together''.
> Hence users should be taught (in the 2nd or 3rd part, not the
> 1st one of their introduction to R)
> to work with R scripts, writing functions etc.

Right, I agree here too.  This would soften the shock of the 1st
introduction, but as soon as the students are ready to look at functions
and understand default parameters, they'd be able to see that the
default value for the "file" argument is file.choose().   They might
become curious about it and call it by itself and discover that it is
possible to program GUI elements (assuming that file.choose() calls one).

> And similar to Marc, I would never want default behavior to
> start up a GUI elements: It is also much more error-prone; just
> consider the  "choose CRAN mirror" GUI that we had recently
> introduced, and the many questions and "bug" reports it produced.
>
> I know that I am biased in my views here;
> but I strongly advocate the  "useRs becoming programmeRs" theme
> and hence rather keep R consistent as a programming language,
> partly agreeing with Gabor here.

I think I disagree with you because I think GUI programming is
programming.  I don't want beginners to think that there are two kinds
of programs:  command-line programs that they can write, and GUI
programs that only Microsoft can write.  I want them to think that
programming is programming.  Doing complex things is harder than doing
easy things, but it's not qualitatively different.

Duncan Murdoch

>     >> The same issue could be made over scan(), where the
>     >> current default is useful.
>
>     Duncan> scan() is very useful for small reads, and rarely
>     Duncan> needed for reading big formatted files,
>
> {people might disagree with this; given scan() is more efficient
>  for large files;  but that's not really the topic here.}
>
>     Duncan> so I wouldn't propose to change it.  
> good.
>
>     Duncan> The inconsistency
>     Duncan> with read.table would be unfortunate, but no worse
>     Duncan> than the current one.
>
>
>     >>> A lot of the issues seem to be user errors, file
>     >>> permission errors, hidden extensions as is pointed out
>     >>> below and related issues. If there is a legitimate bug
>     >>> in R resulting in these issues, then let's patch
>     >>> that. However, I don't think that I can recall
>     >>> reproducible situations where a bug in R is the root
>     >>> cause of these problems.
>
>     >>  Nor I.
>     >>
>     >> Note that file.choose does not protect you against file
>     >> permission issues (actually, on a command-line Unix-alike
>     >> it does nothing much useful at all):
>     >>
>     >>> readLines(file.choose())
>     >> Enter file name: errs.txt
>
>     Duncan> No, it's not helpful here, but again it makes things
>     Duncan> no worse, and there's always the possibility that
>     Duncan> someone would improve file.choose().
>
> I strongly prefer the current usage
>
>   read.table(file.choose(), ....)
>
> which implicitly ``explains'' how the file name is chosen to a
> new default
>   read.table( .....)
>
> I'd like basic R functions not to call menu(), GUI... parts
> unless it's really the main task of that function.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] help with read.table() function

Martin Maechler
>>>>> "Duncan" == Duncan Murdoch <[hidden email]>
>>>>>     on Mon, 30 Jan 2006 09:58:23 -0500 writes:

    Duncan> On 1/30/2006 4:16 AM, Martin Maechler wrote:
    >>>>>>> "Duncan" == Duncan Murdoch <[hidden email]> on
    >>>>>>> Sun, 29 Jan 2006 16:35:50 -0500 writes:
    >>
    Duncan> On 1/29/2006 1:29 PM, Prof Brian Ripley wrote:
    >> >> On Sun, 29 Jan 2006, Marc Schwartz wrote:
    >> >>
    >> >>> I would argue against this.
    >> >>>
    >> >>> If this were the default, that is requiring user >>>
    >> interaction, it would break a fair amount of code that I
    >> >>> (and I am sure a lot of others have) where automation
    >> is >>> critical.
    >>
    >> >> I don't see how.  The current default is
    >> >>
    >> >>> read.table() >> Error in read.table() : argument
    >> "file" is missing, with >> no default
    >> >>
    >> >> so the only change is that the default might do
    >> something >> useful.
    >> >>
    >> >> Nor do I see the change would help, as the same people
    >> >> would still use a character string for 'file' and not
    >> >> omit the argument.  (It seems very unlikely that they
    >> >> would read any documentation that suggested things had
    >> >> changed.)
    >>
    Duncan> No, but people teaching new users (or answering
    Duncan> R-help questions) would have a simpler answer: just
    Duncan> use read.table().
    >>  but I am not sure that people teaching R should advocate
    >> such a read.table; I they did, the new R users would get
    >> the concept that this is the way how to use R.

    Duncan> I'd say "a way to use R", and I think teachers
    Duncan> *should* present such a use.  It insulates users
    Duncan> from uninteresting details, just as now it's
    Duncan> probably good to advocate using file.choose() rather
    Duncan> than explaining paths and escape characters before
    Duncan> beginners can do anything with data.  Later on
    Duncan> they'll need to learn those things, but not from the
    Duncan> beginning.

    >> I still think R should eventually be used for
    >> "Programming with Data" rather than a GUI for ``clicking
    >> results together''.  Hence users should be taught (in the
    >> 2nd or 3rd part, not the 1st one of their introduction to
    >> R) to work with R scripts, writing functions etc.

    Duncan> Right, I agree here too.  This would soften the
    Duncan> shock of the 1st introduction, but as soon as the
    Duncan> students are ready to look at functions and
    Duncan> understand default parameters, they'd be able to see
    Duncan> that the default value for the "file" argument is
    Duncan> file.choose().  They might become curious about it
    Duncan> and call it by itself and discover that it is
    Duncan> possible to program GUI elements (assuming that
    Duncan> file.choose() calls one).

    >> And similar to Marc, I would never want default behavior
    >> to start up a GUI elements: It is also much more
    >> error-prone; just consider the "choose CRAN mirror" GUI
    >> that we had recently introduced, and the many questions
    >> and "bug" reports it produced.
    >>
    >> I know that I am biased in my views here; but I strongly
    >> advocate the "useRs becoming programmeRs" theme and hence
    >> rather keep R consistent as a programming language,
    >> partly agreeing with Gabor here.

    Duncan> I think I disagree with you because I think GUI
    Duncan> programming is programming.  I don't want beginners
    Duncan> to think that there are two kinds of programs:
    Duncan> command-line programs that they can write, and GUI
    Duncan> programs that only Microsoft can write.  I want them
    Duncan> to think that programming is programming.  Doing
    Duncan> complex things is harder than doing easy things, but
    Duncan> it's not qualitatively different.

Actually, I completely agree with what you said here.

However we disagree to some extent about the implications
(on teaching R, learning R, ..) of making GUI elements defaults
for basic R functions.  
Also the phrase  "consistent as a programming language"  was
about the fact that for some functions, the default file(name) would be
GUI-dispatching whereas for other functions it would not (and
you agreed it should not).

Martin

    Duncan> Duncan Murdoch

    >> >> The same issue could be made over scan(), where the >>
    >> current default is useful.
    >>
    Duncan> scan() is very useful for small reads, and rarely
    Duncan> needed for reading big formatted files,
    >>  {people might disagree with this; given scan() is more
    >> efficient for large files; but that's not really the
    >> topic here.}
    >>
    Duncan> so I wouldn't propose to change it.
    >> good.
    >>
    Duncan> The inconsistency with read.table would be
    Duncan> unfortunate, but no worse than the current one.
    >>
    >>
    >> >>> A lot of the issues seem to be user errors, file >>>
    >> permission errors, hidden extensions as is pointed out
    >> >>> below and related issues. If there is a legitimate
    >> bug >>> in R resulting in these issues, then let's patch
    >> >>> that. However, I don't think that I can recall >>>
    >> reproducible situations where a bug in R is the root >>>
    >> cause of these problems.
    >>
    >> >> Nor I.
    >> >>
    >> >> Note that file.choose does not protect you against
    >> file >> permission issues (actually, on a command-line
    >> Unix-alike >> it does nothing much useful at all):
    >> >>
    >> >>> readLines(file.choose()) >> Enter file name: errs.txt
    >>
    Duncan> No, it's not helpful here, but again it makes things
    Duncan> no worse, and there's always the possibility that
    Duncan> someone would improve file.choose().
    >>  I strongly prefer the current usage
    >>
    >> read.table(file.choose(), ....)
    >>
    >> which implicitly ``explains'' how the file name is chosen
    >> to a new default read.table( .....)
    >>
    >> I'd like basic R functions not to call menu(),
    >> GUI... parts unless it's really the main task of that
    >> function.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel