Hi,
On Tue, Nov 25, 2003 at 09:17:09AM +1300, Paul Murrell wrote:
> Hi
>
> Peter Dalgaard wrote:
> > [EMAIL PROTECTED] writes:
> >
> >>Full_Name: Stephen Harker
> >>Version: 1.80
> >>OS: linux (Yellow Dog 3.0 on ppc)
> >>Submission from: (NULL) (130.194.13.101)
> >>
> >>
> >>In creating a postscr
Douglas Bates <[EMAIL PROTECTED]> writes:
> (Reply moved to R-devel where it may be more appropriate.)
>
> "Liaw, Andy" <[EMAIL PROTECTED]> writes:
>
>> > From: Douglas Bates [mailto:[EMAIL PROTECTED]
>> >
>> > "Liaw, Andy" <[EMAIL PROTECTED]> writes:
>> >
>> > > Sorry. I need to retract my cla
Douglas Bates wrote:
I wonder if R&R thought when they started out that they would one day
see something like that.
I think that's a pretty firm no.
I seem to recall that we were targetting 512k Macintoshes.
In our dreams we might have seen 16Mb Sun.
--
Ross Ihaka Email:
(Reply moved to R-devel where it may be more appropriate.)
"Liaw, Andy" <[EMAIL PROTECTED]> writes:
> > From: Douglas Bates [mailto:[EMAIL PROTECTED]
> >
> > "Liaw, Andy" <[EMAIL PROTECTED]> writes:
> >
> > > Sorry. I need to retract my claim. There seems to be a 3G
> > > limit, even though
On Tue, 25 Nov 2003 21:22:08 + (GMT), Prof Brian Ripley
<[EMAIL PROTECTED]> wrote :
>On 25 Nov 2003, Peter Dalgaard wrote:
>
>> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>
>> > On Tue, 25 Nov 2003 15:47:01 + (GMT), Prof Brian Ripley
>> > <[EMAIL PROTECTED]> wrote :
>> >
>> > >This is a
On 25 Nov 2003, Peter Dalgaard wrote:
> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
> > On Tue, 25 Nov 2003 15:47:01 + (GMT), Prof Brian Ripley
> > <[EMAIL PROTECTED]> wrote :
> >
> > >This is a long-known problem: one example is the MASS example in the
> > >script ch15.R, and that has gone
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> On Tue, 25 Nov 2003 15:47:01 + (GMT), Prof Brian Ripley
> <[EMAIL PROTECTED]> wrote :
>
> >This is a long-known problem: one example is the MASS example in the
> >script ch15.R, and that has gone wrong on platforms other than Windows.
> >It has b
On Tue, 25 Nov 2003 15:47:01 + (GMT), Prof Brian Ripley
<[EMAIL PROTECTED]> wrote :
>This is a long-known problem: one example is the MASS example in the
>script ch15.R, and that has gone wrong on platforms other than Windows.
>It has been reported to the maintainer in the past.
Should we b
On Tue, 25 Nov 2003, Prof Brian Ripley wrote:
> I am explicitly not prepared to `refactor' MASS. Not only is it
> explicitly support software for a book (which references it and those
> references cannot be changed retrospectively), it also represents much
> work over many years. Not that we get
This is a long-known problem: one example is the MASS example in the
script ch15.R, and that has gone wrong on platforms other than Windows.
It has been reported to the maintainer in the past.
On Tue, 25 Nov 2003, Duncan Murdoch wrote:
> On Tue, 25 Nov 2003 15:51:22 +0100 (CET), [EMAIL PROTECTE
This is a long-known problem: one example is the MASS example in the
script ch15.R, and that has gone wrong on platforms other than Windows.
It has been reported to the maintainer in the past.
On Tue, 25 Nov 2003, Duncan Murdoch wrote:
> On Tue, 25 Nov 2003 15:51:22 +0100 (CET), [EMAIL PROTECTE
On Tue, 25 Nov 2003 15:51:22 +0100 (CET), [EMAIL PROTECTED]
wrote :
>Full_Name: jean coursol
>Version: 1.7.1, 1.8.0
>OS: linux & Windows-XP
>Submission from: (NULL) (129.175.52.7)
>
>
>Binary MS-Windows akima module from CRAN (1.8.0 version) produces wrong results
>with some data.
This isn't an R
> "jean" == jean coursol <[EMAIL PROTECTED]>
> on Tue, 25 Nov 2003 15:33:58 +0100 (CET) writes:
jean> Full_Name: jean coursol Version: 1.7.1, 1.8.0 OS:
jean> linux Submission from: (NULL) (129.175.52.7)
jean> w <- pwilcox(1000,50,50) allocates the whole memory
jean> a
Full_Name: jean coursol
Version: 1.7.1, 1.8.0
OS: linux & Windows-XP
Submission from: (NULL) (129.175.52.7)
Binary MS-Windows akima module from CRAN (1.8.0 version) produces wrong results
with some data.
Installing akima source in linux, with same data:
-with gcc-2.95.3 -O2 : give correct resul
> From: John Fox
>
> Dear Gregory, Paul, and Jan,
>
> I recall proposing something like this (that is, a classification of
> available functions) some time ago, but it never got off the
> ground. The
> advantage of using keywords is that package authors would
> classify their
> own functions
Full_Name: jean coursol
Version: 1.7.1, 1.8.0
OS: linux
Submission from: (NULL) (129.175.52.7)
w <- pwilcox(1000,50,50) allocates the whole memory and freezes the system
or qwilcox
or dwilcox
To fix the problem: in wilcox.c, call wilcox_free() before return in the three
functions dwi
Dear Gregory, Paul, and Jan,
I recall proposing something like this (that is, a classification of
available functions) some time ago, but it never got off the ground. The
advantage of using keywords is that package authors would classify their
own functions, but I don't think that the current s
Actually that's what I currently do using something like:
readLines(pipe("cmd /c dir/b \\myfolder\\a*.txt"))
but its a pain since:
1. One has to explicitly paste together the filename from the
output of dir with the directory path to create a complete
path/filename for use in other commands
On Tue, 25 Nov 2003 13:29:50 +0100 (CET), you wrote:
>I think you should test for OS ( R.Version()$os )
>
>The special meaning of "c:file" on Windows does not exist on
>Unix, even if the filesystem is on a mounted Windows partition.
The patch does that implicitly by an "#ifdef Win32" in the sourc
On Tue, 25 Nov 2003 07:27:46 -0500 (EST), you wrote:
>
>Perhaps the dir= and pattern= arguments could be combined so that
>its not necessary to for list.files to paste them together:
>
> list.files("C:/a*.txt", glob=T)
Why not use system() or shell() instead? Those explicitly do what ls
or dir
On Mon, 24 Nov 2003 17:12:24 -0500, you wrote:
>I propose that from time to time the R community go through the complete set
>of packages and 'refactor' the functions and data sets into packages that
>have clearly defined goals.
Package 'foreign' is currently such a multi-author common purpose
# aldus Duncan Murdoch :
> On Tue, 25 Nov 2003 07:35:57 + (GMT), you wrote:
>
>
> >I think there are some potential issues with doubling separators and final
> >separators on dirs. On Unix file systems /part1//part2 and /path/to/dir/
> >are valid. However, file systems on Unix may not be Uni
Perhaps the dir= and pattern= arguments could be combined so that
its not necessary to for list.files to paste them together:
list.files("C:/a*.txt", glob=T)
Date: Tue, 25 Nov 2003 07:14:49 -0500
From: Duncan Murdoch <[EMAIL PROTECTED]>
To: Prof Brian Ripley <[EMAIL PROTECTED]>
Cc: <[EMA
On Tue, 25 Nov 2003 07:35:57 + (GMT), you wrote:
>I think there are some potential issues with doubling separators and final
>separators on dirs. On Unix file systems /part1//part2 and /path/to/dir/
>are valid. However, file systems on Unix may not be Unix file systems:
>examples are earlie
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> I think there are some potential issues with doubling separators and final
> separators on dirs. On Unix file systems /part1//part2 and /path/to/dir/
> are valid. However, file systems on Unix may not be Unix file systems:
> examples are earlier Ma
On Mon, 24 Nov 2003, Duncan Murdoch wrote:
> >Duncan Murdoch <[EMAIL PROTECTED]> writes:
> >
> >> Gabor Grothendieck pointed out a bug to me in list.files(...,
> >> full.name=TRUE), that essentially comes down to the fact that in
> >> Windows it's not always valid to add a path separator (slash or
I am explicitly not prepared to `refactor' MASS. Not only is it
explicitly support software for a book (which references it and those
references cannot be changed retrospectively), it also represents much
work over many years. Not that we get much credit for it, but we do get
some and these days
27 matches
Mail list logo
