similar to: system (PR#133)

I've put up R-0.63.3.tgz up for FTP from Auckland some minutes ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.63.3.tgz (Be gentle, that's my desktop PC!) There's also a version split in

I've put up R-0.63.3.tgz up for FTP from Auckland some minutes ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.63.3.tgz (Be gentle, that's my desktop PC!) There's also a version split in

The planned release of R 1.1.0 will be next Thursday. The development version is going into feature freeze tomorrow, meaning that we'll only do testing and fix simple bugs during the next week. Those of you who prefer to find bugs before releases instead of afterwards may want to try it out and tell us what crawls out. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_

I can confirm this bug has been solved, by the expedient of removing the incorrect functions! I think the simplest way to get a bug closed is to send the correction to the original reporter for confirmation, then as Peter suggests send a follow-up to R-bugs. On Fri, 6 Apr 2001 p.dalgaard@biostat.ku.dk wrote: > Paul Gilbert <pgilbert@bank-banque-canada.ca> writes: > > > Peter

Hi, First of all let me thank Prof. Ripley and Peter Dalgaard for their suggestions about ways to debug my initial problem. Debugger() suggested by Prof. Ripley could have provided the definitive answer hadn't it itself be somewhat flaky. Anyway it still helped a lot to pinpoint the problem. The problem turned out to be an old R "deficiency" that showed up again when I used the

Prof Brian Ripley <ripley@stats.ox.ac.uk> writes: > "[<-.zoffset" <- function(x, i, j, value) > { > if(!missing(i) && is.numeric(i)) i <- i+1 > if(!missing(j) && is.numeric(j)) j <- j+1 > NextMethod("[<-") > } > works in S but not in R. (Which I think is a bug.) I next tried Yup, there's a bug in there

Paul Gilbert <pgilbert@bank-banque-canada.ca> writes: > Peter > > I'm not sure how to close a bug report. This problem should be fixed in the version > now loaded on CRAN, although there may be other still to be discovered problems under > Windows. > > Paul Gilbert > _____ > * PR# 781 * > Subject: syskern fails Rcmd check on Windows, gives incorrect

Prof Brian Ripley <ripley@stats.ox.ac.uk> writes: > Except that there is nothing reproducible in that report, not even the > claimed (by Don MacQueen) incorrect lines! Er, right, sorry. Here's a version of the effect, for inclusiont with the report: postscript() x <- seq(0,2*pi,,50000) plot(x,sin(x),type="l") dev.off() Count reduced from the original 200000 to

Don MacQueen <macq@llnl.gov> writes: > When I run the example in R 1.6.2, and view it with gs, I get a good plot. > When I run the example in R 1.7.0, and view it with gs, I get a bad plot. > (run on the same host) > > My "bad plot" is as described by Stephen. ... > (followed by ~200000 lines of the same type, with slowly changing values) > > In the

Thanks to Peter Dalgaard and Suchandra Thapa for answering my question! Before I settle on a particular option, I'd like to ask one more question if I may: Are there any practical advantages to compiling R to 64-bit vs 32-bit? Regards, Andy > -----Original Message----- > From: Peter Dalgaard BSA [mailto:p.dalgaard at biostat.ku.dk] > Sent: Thursday, April 18, 2002 4:19 PM > To:

Dear Peter, Thank you very much for your kind and helpful reply. As I mentioned in a followup email to r-bugs, indeed, one aspect of this issue is a (user specified) shorter stack than that expected by R -- I had only allowed 1 MB of stack space a long long time ago, and forgotten about it. Due to a glitch with r-bugs@r-project.org, I ended up submitting this bug twice, and your original

If I'm not mistaken, "bundle" is really only useful as a concept for distribution and installation. You distribute and install a bundle, but load the individual packages when you want to use them. Once you install the bundle, you won't see the name of the bundle in the list of installed packages, but you see the constituent packages, and those are what you load when you want to

I agree with the the comments below on "Numerical recipes". We developed some commercial software using the code and tried to get a licence. They never responded to our corresponce :-) We also mailed them fixes to some bugs !!! but never heard anything. So we threw their code away and wrote our own... it was a waste of time using the book. Kim On Thursday, 25 November 1999 6:41,

For small datasets it would be useful to be able to copy a block of data from a spreadsheet then toggle over to R and just paste it in. If it's possible, having read.table access the clipboard (e.g. x <- read.table(file="clipboard", ...) would do the trick. Of course, exporting to a file and the reading into R is pretty easy but usring the clipboard would save a couple extra

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

On 09/29/2017 09:30 PM, rick sanchez wrote: > I am trying to get up geo replication between two gluster volumes > > I have set up two replica 2 arbiter 1 volumes with 9 bricks > > [root at gfs1 ~]# gluster volume info > Volume Name: gfsvol > Type: Distributed-Replicate > Volume ID: c2fb4365-480b-4d37-8c7d-c3046bca7306 > Status: Started > Snapshot Count: 0 > Number

TASK: problem with "glm" with binomial errors STATUS: Open FROM: p.dalgaard@kubism.ku.dk in glm(,binomial) it's possible that loss of significant digits make expected values 0 or 1 even though there's no divergence of the fit. (Happened to me with menarche data, infants and grown-ups included) [ Need the example data. Glm needs a

Faheem Mitha <faheem@email.unc.edu> writes: > Dear Dr. Dalgaard, > > I am sending this message only to you since it is probably not of general > interest. Forward it to anyone you like. > > Congratulations to the R development team on the release of version 1.0.0 > of R. If you will excuse me asking, I was wondering if there are any plans > to release a rpm of

Just to update: What I originally thought was a glm problem appears to be a memory problem that occurs only when R is compiled with the DEC C compiler. Some variables that are still in use get clobbered during garbage collection. No problems if I compile with gcc though. I've made some attempts to see if I can identify a specific compiler optimization that is responsible, but so far no luck.