[Rd] issue with parallel package
Dear maintainers of the parallel package,
I ran into an issue with the parallel package in R-3.1.0.
The following code prints the message "NULL!" quite a lot.
library(parallel)
for (n in 1:1000) {
p <- mcparallel(sqrt(n))
res <- mccollect(p, wait=FALSE, timeout=1000)
mccollect(p)
if (is.null(res)) cat(n," NULL!\n")
}
It does not happen in R-3.0.3.
(To be exact, I have checked out R-devel revision r65130
for my current tests.)
I found that this behavior is introduced in revision r65143.
When I insert
Sys.sleep(0.1)
in the loop then this behavior disappears in R-3.1.0.
There is also another difference between R-3.1.0 and R-3.0.3:
When the line
mccollect(p)
is replaced by
mccollect(p, wait=FALSE, timeout=1000)
then in R-3.1.0 some child processes are not terminated and some
pipes remain open. This does not happen in R-3.0.3.
Remark:
If the line
mccollect(p)
is omitted at all then "NULL!" is never printed but
R aborts after 510 iterations of the loop with the message
"Error in mcfork(detached) : unable to create a pipe".
Then none of the child processes is terminated and
number of possible open pipes is exhausted.
Is this behavior intended or a bug?
> version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 3
minor 1.0
year 2014
month 04
day10
svn rev65387
language R
version.string R version 3.1.0 (2014-04-10)
nickname Spring Dance
best whishes
Josef
--
---------
Josef Leydold
Institute for Statistics and Mathematics
WU (Vienna University of Economics and Business)
Welthandelsplatz 1, Building D4, 1020 Vienna, Austria
Phone +43 1 31336 4695 FAX +43 1 31336 904695 email josef.leyd...@wu.ac.at
-
Alles Unglueck kam daher, dass die Denkenden nicht mehr handeln konnten,
und die Handelnden keine Zeit mehr fanden zu denken. (Marlen Haushofer)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Buglet in qbeta?
Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.00e+00 1.253990e-201 1.589622e-171 6.462785e-154 2.015085e-141 [6] 9.892240e-132 8.192553e-124 4.056003e-117 2.554424e-111 3.330774e-106 [11] 1.253990e-101 1.728076e-97 1.038529e-93 3.109063e-90 5.141594e-87 [16] 5.098238e-84 3.238117e-81 1.390549e-78 4.58e-76 9.411402e-74 [21] 1.589622e-71 2.090373e-69 2.190596e-67 1.866714e-65 1.316493e-63 [26] 7.803602e-62 3.941205e-60 1.716606e-58 6.517745e-57 2.178181e-55 [31] 6.462785e-54 1.715788e-52 4.104801e-51 8.906113e-50 1.762731e-48 [36] 3.199622e-47 5.352348e-46 8.288322e-45 1.193037e-43 1.602341e-42 [41] 2.015085e-41 2.380564e-40 2.649862e-39 2.787018e-38 2.776910e-37 [46] 2.627517e-36 2.366341e-35 2.032732e-34 1.668853e-33 1.311905e-32 [51] 9.892240e-32 2.220446e-15 2.331468e-15 2.553513e-15 1.110223e-16 [56] 3.330669e-16 9.992007e-16 8.881784e-16 4.440892e-16 7.771561e-16 [61] 1.554312e-15 8.881784e-16 9.992007e-16 2.109424e-15 2.331468e-15 [66] 2.553513e-15 2.553513e-15 1.110223e-16 6.661338e-16 1.221245e-15 [71] 1.443290e-15 2.220446e-16 6.661338e-16 2.664535e-15 1.054712e-14 [76] 4.019007e-14 1.512124e-13 5.589973e-13 2.031153e-12 7.261081e-12 [81] 2.554423e-11 8.847001e-11 3.017724e-10 1.014153e-09 3.359099e-09 [86] 1.096950e-08 3.532966e-08 1.122586e-07 3.520157e-07 1.089674e-06 [91] 3.330818e-06 1.005659e-05 3.50e-05 8.845884e-05 2.579427e-04 [96] 7.446202e-04 2.133444e-03 6.108393e-03 1.783085e-02 5.699554e-02 [101] 1.00e+00 > order(x) [1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 55 68 72 [55] 56 59 69 73 60 58 62 57 63 70 71 61 64 52 53 65 54 66 [73] 67 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [91] 91 92 93 94 95 96 97 98 99 100 101 > pbeta(x,0.01,5) [1] 0.000 0.010 0.020 0.030 0.040 0.050 0.060 [8] 0.070 0.080 0.090 0.100 0.110 0.120 0.130 [15] 0.140 0.150 0.160 0.170 0.180 0.190 0.200 [22] 0.210 0.220 0.230 0.240 0.250 0.260 0.270 [29] 0.280 0.290 0.300 0.310 0.320 0.330 0.340 [36] 0.350 0.360 0.370 0.380 0.390 0.400 0.410 [43] 0.420 0.430 0.440 0.450 0.460 0.470 0.480 [50] 0.490 0.500 0.7285871 0.7289426 0.7296061 0.7070842 0.7148952 [57] 0.7227924 0.7219416 0.7169548 0.7209782 0.7259930 0.7219416 0.7227924 [64] 0.7282134 0.7289426 0.7296061 0.7296061 0.7070842 0.7198677 0.7242443 [71] 0.7254552 0.7120024 0.7198677 0.7299167 0.7400284 0.7499948 0.7599988 [78] 0.778 0.778 0.790 0.800 0.810 0.820 0.830 [85] 0.840 0.850 0.860 0.870 0.880 0.890 0.900 [92] 0.910 0.920 0.930 0.940 0.950 0.960 0.970 [99] 0.980 0.990 1.000 > version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 2 minor 11.0 year 2009 month 10 day07 svn rev49963 language R version.string R version 2.11.0 Under development (unstable) (2009-10-07 r49963) p.s. there are similar results for R-2.9.2 in Windows (with different round-off errors). -- --------- Josef Leydold | WU (Vienna University of Economics and Business) | Department of Statistics and Mathematics - Augasse 2-6 | Te
[Rd] possible bug in formals
Hi,
I am a little bit surprised by the following output of
'formals'. Is this the intended behavior?
> f <- function(a=1,b=-1) { a+b }
> class(formals(f)$a)
[1] "numeric"
> class(formals(f)$b)
[1] "call"
Josef
--
-----
Josef Leydold | WU (Vienna University of Economics and Business)
| Institute for Statistics and Mathematics
-
Augasse 2-6 | Tel. +43 1 31336 4695
A-1090 Vienna | FAX+43 1 31336 774
European Union | email josef.leyd...@wu.ac.at
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in formals
Dear Brian and Uwe,
Thanks a lot for the clarification.
I made the naive assumption that numeric constants in R are similar to
those in C.
Two questions still remain:
(1) when I have a function
f<- function(a=1,b=-1) { a+b }
is it safe to use
val <- as.character(deparse(formals(f)$b))
to obtain a string that contains the default value for
argument "b". (Does is also work for other arguments with some
default of arbitrary class?)
(2) I have seen that packages like gWidget (in function ggenericwidget)
use a statement like
switch(class(formals(f)$b),
numeric = { },
character = { },
class = { },
for automatically processing function arguments.
in the case of "b=-1" this procedure obviously fails.
(I found this behavior of 'formals' while playing around with
packages "gWidgets" and "fgui" from CRAN).
Is there a safe workaround for this problem?
That is, is there a safe function that returns class
"numeric" for an exresion like "-1" or "-Inf"?
Josef
On Sun, May 23, 2010 at 03:52:00PM +0100, Prof Brian Ripley wrote:
> Documented too: from ?NumericConstants
>
> Note that a leading plus or minus is not regarded by the parser as
> part of a numeric constant but as a unary operator applied to the
> constant.
>
>
>
> On Sun, 23 May 2010, Uwe Ligges wrote:
>
> >
> >
> > On 23.05.2010 16:14, Josef Leydold wrote:
> >> Hi,
> >>
> >> I am a little bit surprised by the following output of
> >> 'formals'. Is this the intended behavior?
> >>
> >>> f<- function(a=1,b=-1) { a+b }
> >>> class(formals(f)$a)
> >> [1] "numeric"
> >>> class(formals(f)$b)
> >> [1] "call"
> >>
> >>
> >> Josef
> >>
> >>
> >
> >
> > Yes, the arguments have not yet been evaluated, hence -1 is still a
> > language
> > object.
> >
> > Try to write
> > f<- function(a= +1, b= -1) { a+b }
> > and you will find that this is a fascinating feature.
> >
> > Uwe Ligges
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> 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
>
--
-
Josef Leydold | WU (Vienna University of Economics and Business)
| Institute for Statistics and Mathematics
-
Augasse 2-6 | Tel. +43 1 31336 4695
A-1090 Vienna | FAX+43 1 31336 774
European Union | email josef.leyd...@wu.ac.at
-
Alles Unglueck kam daher, dass die Denkenden nicht mehr handeln konnten,
und die Handelnden keine Zeit mehr fanden zu denken. (Marlen Haushofer)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dchisq hangs in infinite loop (PR#13309)
Full_Name: Josef Leyold Version: 2.9.0 (2008-11-20 r46997) OS: Linux Submission from: (NULL) (137.208.56.12) Hi, the command dchisq(x=Inf,df=10,ncp=1) causes R to hang in an (almost?) infinite loop. It also happens for x=1.e50. Josef p.s. the problem also occurs in version 2.7.2 > R.version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 2 minor 9.0 year 2008 month 11 day20 svn rev46997 language R version.string R version 2.9.0 Under development (unstable) (2008-11-20 r46997) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warning from R CMD build
Hi,
I wonder about the reason for the following lines:
$ diff ~/local/lib64/R/bin/build /usr/lib64/R/bin/build
40c40
< my $revision = ' $Rev: 46832 $ ';
---
> my $revision = ' $Rev: 45803 $ ';
576,579d570
< if(-r "Makevars") {
< $makefiles .= " -f Makevars";
< R_system("${R::Vars::MAKE} $makefiles clean");
< }
it produces a warning like
$ R-devel CMD build Runuran
[...]
* DONE (Runuran)
* creating vignettes ... OK
* cleaning src
make: *** No rule to make target `clean'. Stop.
* running cleanup
* removing junk files
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'Runuran_0.8.900.tar.gz'
"Writing R Extensions" however says:
Note that @file{Makevars} should not normally contain targets, as it is
(except on Windows) included before the default makefile and
@command{make}
is called without an explicit target.
Josef
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 classes and methods with optional arguments
Hi,
i have used S4 classes to implement a unified access to random number generators
(package rstream on CRAN).
I have used a construct to allow optional arguments:
if(!isGeneric("rstream.sample"))
setGeneric("rstream.sample", function(stream,...)
standardGeneric("rstream.sample"))
setMethod("rstream.sample", c("rstream","numeric"),
function(stream,n=1) { ... [ code ] ... } )
Thus if rs is an instance of an rstream object one can a random
sample of size 10 using
rstream.sample(rs, 10)
for a sample of size 1 one can use equivalently
rstream.sample(rs,1)
rstream.sample(rs)
however, with R-devel the above construct does not work any more, due to
more stringent checkings. It can be fixed by replacing it by
if(!isGeneric("rstream.sample"))
setGeneric("rstream.sample", function(stream,n)
standardGeneric("rstream.sample"))
setMethod("rstream.sample", c("rstream","numeric"),
function(stream,n=1) { ... [ code ] ... } )
then rstream.sample(rs) does not work any more.
Is there still a way to allow optional arguments for methods of
S4 classes?
Josef
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Interface for package supplied random number generator
Hi, As you probably know, there is a problem with the interface for adding uniform random number generators in R (see by article in R News 5/2, November 2005). There exists a mechanism called "user-supplied" that allows users of R to run their own generator in R. However, there is no such mechanism for package writers. Those who want to add their own generators abuse RNGkind(kind="user-supplied") for their purpose. The problem with this approach is that it relies on the unique existence of the function "user_unif_rand". When two packages are loaded that use this interface, then at least one package is broken. If the user herself loads a shared library that contains such a function, some of the functionalities of all the corresponding packages are broken. When writing my paper I found the following packages on CRAN that abuse this interface (meanwhile there might be more packages): randaes_0.1.tar.gz rlecuyer_0.1.tar.gz rsprng_0.3-1.tar.gz rstream_1.1.tar.gz SuppDists_1.0-13.tar.gz what makes the situation even more complicated is the fact that some of these packages are loaded automaticall by other packages. For example, package 'rlecuyer' is loaded by snow_0.2-1.tar.gz snowFT_0.0-1.tar.gz varSelRF_0.6-2.tar.gz To solve this problem, Stefan Theussl and I have tried to extend the mechanism for random number generators in the following way: - we have added a new kind of generators: "package-supplied" - this generator kind needs functions named 'package_unif_rand', 'package_unif_init', 'package_unif_nseed', and 'package_unif_seedloc' (analogously to the functions for kind "user-supplied") - RNGkind has an additional optional argument: RNGkind <- function(kind = NULL, normal.kind = NULL, PACKAGE = "") argument 'PACKAGE' is only used for the new generator kind "package-supplied" - similarly the function set.seed needs the optinal argument 'PACKAGE' Since I need such an extended interface (and I assume that other package write do also) I ask whether this extension can be included into R. We have implemented a first experimental version of this modified interface. A patch against the development snapshot R-devel_2006-08-30.tar.gz is available. However, it is a little bit too long (239 lines) to be posted here. Of course suggestions for an alternative approach are welcome. Josef -- - Josef Leydold | Vienna University of Economics and Business Administration | Department of Statistics and Mathematics - Augasse 2-6 | Tel. +43 1 31336 4695 A-1090 Vienna | FAX+43 1 31336 774 European Union | email [EMAIL PROTECTED] - Alles Unglueck kam daher, dass die Denkenden nicht mehr handeln konnten, und die Handelnden keine Zeit mehr fanden zu denken. (Marlen Haushofer) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
