similar to: qbeta function (FYI, compiler bug)

Full_Name: Morten Welinder Version: 1.6.1 OS: Solaris/sparc Submission from: (NULL) (65.213.85.144) qbeta(0.1, 1e-8, 0.5, TRUE, FALSE) seems to hang for me.

Full_Name: M Welinder Version: 1.4 OS: (src) Submission from: (NULL) (192.5.35.38) It seems to me that pexp can be improved in the lower_tail=TRUE and log_p=FALSE case by using expm1. Something like -expm1 (-x / scale); I think. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send

The real problem is that pbeta can take forever. That's bug #7153 and a fix is within reach. Morten

>Date: Fri, 2 May 2003 10:03:23 -0400 (EDT) From: Morten Welinder <welinder@rentec.com> >To: p.dalgaard@biostat.ku.dk >CC: r-devel@stat.math.ethz.ch, R-bugs@biostat.ku.dk >Subject: Re: [Rd] qbeta hang (PR#2894) > >Ok, I can confirm that it does not, in fact, loop forever. Just a close >approximation. ... >There are lots of other places that worry me with respect to

HI All: Does anyone know the code behind the qbeta function in R? I am using it to calculate exact confidence intervals and I am getting 'NaN' at places I shouldnt be. Heres the simple code I am using: k<-3 > x<-NULL > p<-rbeta(k,3,3)# so that the mean nausea rate is alpha/(alpha+beta) > min<-10 > max<-60 > n<-as.integer(runif(3,min,max)) > for(i in

Full_Name: Ziheng Yang Version: 1.3.1 OS: Windows 98 Submission from: (NULL) (172.136.54.89) I noticed that qbeta is sometimes wrong and the error is not even due to the beta parameters being too extreme. I am calculating the quantiles corresponding to cdf = 0.05, 0.15, ..., 0.95. The value corresponding to cdf=0.25 is wrong while all other values are correct. qbeta(0.05, 0.143891, 0.05) =

Full_Name: Morten Welinder Version: 1.5.1 OS: Solaris/Linux Submission from: (NULL) (192.5.35.38) The line return log(1 - p) * (x + 1); looks like it has problems for p near 1. I would suggest rewriting it to return log1p (-p) * (x + 1); -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read

Full_Name: M Welinder Version: 1.4 OS: (src) Submission from: (NULL) (192.5.35.38) It seems to me that pweibull can be improved in the lower_tail=TRUE and log_p=FALSE case by using expm1. Something like -expm1(-pow(x / scale, shape)), I think. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read

Hi all, A hopefully quick query. I was reading a posting over at gnomedesktop.org on the latest release of Gnumeric 1.4: http://gnomedesktop.org/node/2090 There is a mention there: Improved accuracy: While Gnumeric 1.2 was already the best available source for accuracy in statistical calculations, Gnumeric 1.4 is even better. We are cooperating with The R Project to

Given that a number of us are housebound, it might be a good time to try to improve the approximation. It's not an area where I have much expertise, but in looking at the qbeta.c code I see a lot of root-finding, where I do have some background. However, I'm very reluctant to work alone on this, and will ask interested others to email off-list. If there are others, I'll report back.

I've discovered an infelicity (I guess) in qbeta(): it's not a bug, since there's a clear warning about lack of convergence of the numerical algorithm ("full precision may not have been achieved"). I can work around this, but I'm curious why it happens and whether there's a better workaround -- it doesn't seem to be in a particularly extreme corner of parameter

make check of R-alpha_2006-04-08_r37675 fails on Debian GNU/Linux 3.1 running on an Intel P4 computer. > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status

Despite the need to focus on pbeta, I'm still willing to put in some effort. But I find it really helps to have 2-3 others involved, since the questions back and forth keep matters moving forward. Volunteers? Thanks to Martin for detailed comments. JN On 2020-03-26 10:34 a.m., Martin Maechler wrote: >>>>>> J C Nash >>>>>> on Thu, 26 Mar 2020

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.000000e+00 1.253990e-201 1.589622e-171

Full_Name: Tim Massingham Version: 1.2.2 OS: Debian/Linux Submission from: (NULL) (131.111.8.68) In 1.2.2 sources (also in 0.90.1. I haven't been able to check other versions) Line 103 in qbeta.c should read: w = y * sqrt(h + r) / h - (t - s) * (r + 5. / 6. - 2 / (3 * h)); since otherwise the 5 / 6 will evaluate to zero (I think). The Statlib fortran code uses five / six instead. Cheers,

>>>>> Ben Bolker >>>>> on Wed, 25 Mar 2020 21:09:16 -0400 writes: > I've discovered an infelicity (I guess) in qbeta(): it's not a bug, > since there's a clear warning about lack of convergence of the numerical > algorithm ("full precision may not have been achieved"). I can work > around this, but I'm

Full_Name: Morten Welinder Version: 2 OS: Solaris/space/gcc2.95.2 Submission from: (NULL) (65.213.85.217) I changed src/nmath/standalone/test.c to read: --------------------------------------------------------------------------------- #define MATHLIB_STANDALONE 1 #include <Rmath.h> #include <stdio.h> int main() { double x; for (x = 99990; x <= 100009; x++) printf

This is also strange: qbeta <- function (p, shape1, shape2, ncp = 0, lower.tail = TRUE, log.p = FALSE) { if (missing(ncp)) .Call(C_qbeta, p, shape1, shape2, lower.tail, log.p) else .Call(C_qnbeta, p, shape1, shape2, ncp, lower.tail, log.p) } Since the default value is 0 for non-centrality, it seems like the logic above is wrong. When ncp=0, C_qnbeta would be called

>>>>> J C Nash >>>>> on Thu, 26 Mar 2020 09:29:53 -0400 writes: > Given that a number of us are housebound, it might be a good time to try to > improve the approximation. It's not an area where I have much expertise, but in > looking at the qbeta.c code I see a lot of root-finding, where I do have some > background. However,

I need to run qbeta on a set of 500K different parameter pairs (with a fixed quantile). For most pairs qbeta finds the solution very quickly but for a substantial minority of the cases qbeta is very slow. This occurs when the solution is very close to zero. qbeta is getting answers to a precision of about 16 decimal places. I don't need that accuracy. Is there any way to set the precision of