[Rd] fork package problem
I have been using the fork package on a cluster to spawn jobs. I have
noticed that I end up with many "R defunct" (zombie) processes following
the use of fork that do not die completely until I close down R.
Initially, I thought it may be my code but I ran the example from the
latest fork package (see code below) on R.2.3.1 and ended up with the
same problem. The code from the fork package that results in the R
defunct processes is as follows:
{
pid = fork(slave=NULL)
if(pid==0) {
cat("Hi from the child process\n"); exit()
} else {
cat("Hi from the parent process\n");
}
I am running R-2.3.1 Suse10 linux but the same error also occurs with
R.2.2.0.
I thought R-dev would be the most useful place but please suggest
another mailing list if this is in appropriate.
Thanks,
Bill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fork package problem
On 12/15/2006 8:30 AM, billk01 wrote:
> I have been using the fork package on a cluster to spawn jobs. I have
> noticed that I end up with many "R defunct" (zombie) processes following
> the use of fork that do not die completely until I close down R.
> Initially, I thought it may be my code but I ran the example from the
> latest fork package (see code below) on R.2.3.1 and ended up with the
> same problem. The code from the fork package that results in the R
> defunct processes is as follows:
>
> {
> pid = fork(slave=NULL)
> if(pid==0) {
> cat("Hi from the child process\n"); exit()
> } else {
> cat("Hi from the parent process\n");
> }
>
> I am running R-2.3.1 Suse10 linux but the same error also occurs with
> R.2.2.0.
>
> I thought R-dev would be the most useful place but please suggest
> another mailing list if this is in appropriate.
Generally problems with contributed packages should be reported to the
maintainer, in this case Greg Warnes. You can get his email address
from the DESCRIPTION file in the package, or library(help=fork).
Please also see whether the error occurs in the almost-released 2.4.1,
available on CRAN. (This might not be relevant to your problem with
fork, but the more testers, the better!)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fork package problem
On Fri, Dec 15, 2006 at 08:30:05AM -0500, billk01 wrote:
> I have been using the fork package on a cluster to spawn jobs. I have
> noticed that I end up with many "R defunct" (zombie) processes following
> the use of fork that do not die completely until I close down R.
> Initially, I thought it may be my code but I ran the example from the
> latest fork package (see code below) on R.2.3.1 and ended up with the
> same problem. The code from the fork package that results in the R
> defunct processes is as follows:
>
> {
> pid = fork(slave=NULL)
> if(pid==0) {
> cat("Hi from the child process\n"); exit()
> } else {
> cat("Hi from the parent process\n");
> }
>
> I am running R-2.3.1 Suse10 linux but the same error also occurs with
> R.2.2.0.
This is what happens if you don't call wait (as the documentation
of fork demonstrates in an example, if I recall correctly).
Best regards, Jan
--
+- Jan T. Kim ---+
| email: [EMAIL PROTECTED] |
| WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A possible improvement to apropos
> Robert Gentleman writes: > I would vastly prefer apropos to be case insensitive by default. The > point of it is to find things similar to a string, not the same as, and > given that capitalization in R is somewhat erratic (due to many authors, > and some of those changing their minds over the years), I find the > current apropos of little use. > I would also, personally prefer some sort of approximate matching since > there are different ways to spell some words, and some folks abbreviate > parts of words. The same design has been employed by help.search for a long time, for exactly the same reasons (albeit with slightly different agrep defaults). -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A possible improvement to apropos
Kurt Hornik <[EMAIL PROTECTED]> writes: >> Robert Gentleman writes: > >> I would also, personally prefer some sort of approximate matching since >> there are different ways to spell some words, and some folks abbreviate >> parts of words. > > The same design has been employed by help.search for a long time, for > exactly the same reasons (albeit with slightly different agrep > defaults). I may not have spent enough time adjusting the behavior, but when I tried agrep for apropos, I found that I almost always got way too many hits and found the case-insensitive grep the right balance. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A possible improvement to apropos
> Seth Falcon writes: > Kurt Hornik <[EMAIL PROTECTED]> writes: >>> Robert Gentleman writes: >> >>> I would also, personally prefer some sort of approximate matching since >>> there are different ways to spell some words, and some folks abbreviate >>> parts of words. >> >> The same design has been employed by help.search for a long time, for >> exactly the same reasons (albeit with slightly different agrep >> defaults). > I may not have spent enough time adjusting the behavior, but when I > tried agrep for apropos, I found that I almost always got way too many > hits and found the case-insensitive grep the right balance. Have you tried the help.search design? It uses approximate matching only if the match string is long enough (no less than 5 characters, something slightly larger may be useful for apropos()). -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possible bug in co.intervals when overlap=0
I apologize if this is just a misunderstanding on my part, but I was under the impression that the intervals returned by co.intervals should cover all the observations. Yet x<-1:10 z<-co.intervals(x,overlap=0) In R, z equals [,1] [,2] [1,] 0.5 1.5 [2,] 2.5 3.5 [3,] 3.5 4.5 [4,] 5.5 6.5 [5,] 7.5 8.5 [6,] 8.5 9.5 Note in particular the second and last element of x are not covered by any of the intervals. In fact S-PLUS gives [,1] [,2] [1,]12 [2,]33 [3,]45 [4,]67 [5,]88 [6,]9 10 Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] max.col oddity
I've noticed that the max.col function with the default "random"
option often gives unexpected results. For instance, in this test, it
seems clear what the answer should be:
> # second col should always be max
> x1 = cbind(1:10, 2:11, -Inf)
>
> # this works fine
> max.col(x1, "first")
[1] 2 2 2 2 2 2 2 2 2 2
>
> # this gives random answers
> max.col(x1)
> [1] 3 1 1 2 3 3 1 3 1 1
Ouch! max.col is randomizing across all values.
Even without infinite values, something similar can happen:
> # test 2 --- tolerance problems
>
> # clearly column 3 is the max
> x1 = cbind(-1e9 * 1:10, 1:10, 2:11)
>
> # again, first method works:
> max.col(x1, "first")
[1] 3 3 3 3 3 3 3 3 3 3
>
> # but random doesn't
> max.col(x1)
[1] 2 3 2 3 3 2 2 2 3 2
>
The max.col docs say " there is a relative tolerance of 1e-5, relative
to the largest entry in the row", but it's really using the maximum
absolute value entry in the row (appl/maxcol.c, line 35 in R 2.4.0).
Is this necessary for some sort of S-plus compatibility? If so, I
think it would be good to make this absolute value property very clear
in the docs, since it can cause subtle bugs (and did for me).
Personally, I think the behavior is much nicer with the following patch:
--- rplain/R-2.4.0/src/appl/maxcol.c2006-04-09 18:19:58.0 -0400
+++ R-2.4.0/src/appl/maxcol.c 2006-12-14 15:30:56.0 -0500
@@ -26,13 +26,14 @@
do_rand = *ties_meth == 1;
for (r = 0; r < n_r; r++) {
- /* first check row for any NAs and find the largest abs(entry) */
+ /* first check row for any NAs and find the largest entry */
large = 0.0;
isna = FALSE;
for (c = 0; c < *nc; c++) {
a = matrix[r + c * n_r];
if (ISNAN(a)) { isna = TRUE; break; }
- if (do_rand) large = fmax2(large, fabs(a));
+ if (!R_FINITE(a)) continue;
+ if (do_rand) large = fmax2(large, a);
}
if (isna) { maxes[r] = NA_INTEGER; continue; }
END --
This gives the expected behavior in the two examples above.
(Sorry to crosspost to both this list and R-help, but it was suggested
that R-devel would be a more appropriate forum for this.)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in co.intervals when overlap=0
This happens equally when overlap = 0.5 (the default). Yes, it is a bug. R does xr <- x[r + ii] with fractional r. On Fri, 15 Dec 2006, Benjamin Tyner wrote: > I apologize if this is just a misunderstanding on my part, but I was > under the impression that the intervals returned by co.intervals should > cover all the observations. Yet > > x<-1:10 > z<-co.intervals(x,overlap=0) > > In R, z equals > [,1] [,2] > [1,] 0.5 1.5 > [2,] 2.5 3.5 > [3,] 3.5 4.5 > [4,] 5.5 6.5 > [5,] 7.5 8.5 > [6,] 8.5 9.5 > > Note in particular the second and last element of x are not covered by > any of the intervals. In fact S-PLUS gives > [,1] [,2] > [1,]12 > [2,]33 > [3,]45 > [4,]67 > [5,]88 > [6,]9 10 -- Brian D. Ripley, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
