search for: bugously

This is a Request For Comment, also BCCed to 390 package maintainers of reverse dependencies of the Matrix package. Most users and package authors working with our 'Matrix' package will be using it for numerical computations, and so will be using "dMatrix" (d : double precision) matrix objects M, and indirectly, e.g., for M >= c will also use "lMatrix" (l:

>>>>> Martin Maechler >>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >>>>> Hugh Parsonage >>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): >> $> R --vanilla >> x <- c(0L, -2e9:2e9) >> # > Segmentation

On Tue, Apr 25, 2017 at 02:41:58PM +0000, Cook, Malcolm wrote: > Might this combination serve the purpose: > * R session keeps an open handle on the tempdir it creates, > * whatever tempdir harvesting cron job the user has be made sensitive enough not to delete open files (including open directories) Good suggestion but doesn't work with the (increasingly popular)

On Tue, 8 Sep 2020, Hugh Parsonage wrote: > Thanks Martin. On further testing, it seems that the segmentation > fault can only occur when the amount of obtainable memory is > sufficiently high. On my machine (admittedly with other processes > running): > > $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" > Segmentation fault > > $ R --vanilla

Dear r-help@, A while ago I tried to bundle packages for offline installations. For this I created a script that would access ftp://cran.r-project.org/pub/R/src/contrib/ for each package in a loop. The first trial was bugous and it generated many bad URL requests to cran.r-project.org >From that moment I was not able to access r-project.org. My IP address is 87.70.177.68 Can you please help?

>>>>> luke-tierney >>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes: > On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>>> Martin Maechler >>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >> >>>>>>> Hugh Parsonage >>>>>>> on Tue, 8 Sep 2020

Martin wrote: > Just this morning, > I found (again!, we had something close to this before) > the following related bugous behavior : > After interrupting a plot (which would have taken a few minutes and was > "wrong" anyway), starting another plot, interrupting again [with C-c], > and maybe the same once more, > R started just giving a ">" prompt

...r example is what I'd expect is always a possibility on some platforms, all of course depending on low things such as root/syadmin/... "permission" to clean up etc. Jeroeen mentioned the fact that tempdir()s also can disappear for other reasons {his was multicore child processes .. bugously(?) implemented}. Further reasons may be race conditions / user code bugs / user errors, etc. Note that the R process which created the tempdir on startup always has the permission to remove it again. But you can also think a full file system, etc. Current R-devel's tempdir(check = TRUE)...

...ect is always a > possibility on some platforms, all of course depending on low > things such as root/syadmin/... "permission" to clean up etc. > > Jeroeen mentioned the fact that tempdir()s also can disappear > for other reasons {his was multicore child processes > .. bugously(?) implemented}. > Further reasons may be race conditions / user code bugs / user > errors, etc. > Note that the R process which created the tempdir on startup > always has the permission to remove it again. But you can also > think a full file system, etc. > > Current R-deve...

This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I

...possibility on some platforms, all of course depending on low >> things such as root/syadmin/... "permission" to clean up etc. >> >> Jeroeen mentioned the fact that tempdir()s also can disappear >> for other reasons {his was multicore child processes >> .. bugously(?) implemented}. >> Further reasons may be race conditions / user code bugs / user >> errors, etc. >> Note that the R process which created the tempdir on startup >> always has the permission to remove it again. But you can also >> think a full file system, etc. >&...

Thanks Martin. On further testing, it seems that the segmentation fault can only occur when the amount of obtainable memory is sufficiently high. On my machine (admittedly with other processes running): $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" Segmentation fault $ R --vanilla --max-mem-size=29G -e "x <- c(0L, -2e9:2e9)" Error: cannot allocate vector

On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>> Martin Maechler >>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: > >>>>>> Hugh Parsonage >>>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: > > >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): > > >> $> R

Hi Martin I got stung by this last week. glmnet produces a coefficient matrix of class ?dgCMatrix? If a predictor matrix was created using sparseMatrix as follows, one gets unexpected results, as this simple example shows. My fix was easy (I always convert the predictor matrix to class ?dgCMatrix? now) Trevor > y=Matrix(diag(4)) > y 4 x 4 diagonal matrix of class "ddiMatrix"

Hi Martin, package arules heavily relies on ngCMatrix and uses multiplication and addition for logical operations. I think it makes sense that in a mixed operation with one dgCMatrix and one ngCMatrix the ngCMatrix should be "promoted" to a dgCMatrix. The current behavior of %*% and friends is in deed confusing: > m <- matrix(sample(c(0,1), 5*5, replace=TRUE), nrow=5) >

Unfortunately I only get [Thread 21752.0x4aa8 exited with code 3221225477] [Thread 21752.0x4514 exited with code 3221225477] [Thread 21752.0x3f10 exited with code 3221225477] [Inferior 1 (process 21752) exited with code 030000000005] (I'm guessing I would need to build an instrumented version of R, or can R be debugged using gdb with an off-the-shelf installation?) On Wed, 9 Sep 2020 at

...platforms, all of course depending on low >>> things such as root/syadmin/... "permission" to clean up etc. >>> >>> Jeroeen mentioned the fact that tempdir()s also can disappear >>> for other reasons {his was multicore child processes >>> .. bugously(?) implemented}. >>> Further reasons may be race conditions / user code bugs / user >>> errors, etc. >>> Note that the R process which created the tempdir on startup >>> always has the permission to remove it again. But you can also >>> think a full fil...

I'm having trouble grokking complex NaN's. This first set examples using complex(re=NaN,im=NaN) give what I expect > Re(complex(re=NaN, im=NaN)) [1] NaN > Im(complex(re=NaN, im=NaN)) [1] NaN > Arg(complex(re=NaN, im=NaN)) [1] NaN > Mod(complex(re=NaN, im=NaN)) [1] NaN > abs(complex(re=NaN, im=NaN)) [1] NaN and so do the following > Re(complex(re=1,

(Just returning from the "wilds" of Canada, so not able to comment on the specifics, but ...) There is a basic point about generic functions that may be related to the "private" class question and my earlier remarks that Martin alluded to. R (and S4 before it) allows packages to define methods for a generic function in another package. Say, for plot() in graphics. The

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,