similar to: make check of R-alpha_2006-04-08_r37675 fails: qbeta

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) =

Hi there, this is just to let you know that the qbeta function, which was copied from R into Gnumeric, has been confirmed to be miscompiled by gcc 2.96 on Linux. (That's Red Hat's compiler.) This shows by qbeta(0.025,4,0.5) ending up taking the wrong branch of "if (alpha <= 0.5)". We compile things in a different context, so this may or may not affect you. The qbeta

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

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

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.

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

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

> > Hi All: > > I am using R to calculate exact 95% confidence interval using Clopper > Pearson method. I am using the following code but it seems to get into a > loop and not get out of it, it goes on forever although I am looping it > only 10 times across 63 sites with 10 observations per site. I was hoping > to get some help. > > Thanks > Anamika >

>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

I'm writing a C program and I'd like to include in it some R routine (quantile functions, typically). I found the functions I have to use (qnorm.c qbeta.c ecc) e some include (nmath.h rmath.h ecc). But I can't compile the project, I receive linker error. Somebody can help me? I say, if I want to include qbeta (for example) in a project of mine, what should I do?

The current development version dies in qbeta() when compiled with egcs -O, egcs 1.0.2 and glibc 2.0.7 (RedHat versions). Since this also kill the F and t distributions, it doesn't exactly do wonders for R's usefulness... Anyone else seeing this or has my setup just gone out of whack? It does look pretty much like a clear compiler bug when inlining math functions (storing temporaries

Linking my VC++ application with the standalone Rmath library yields the following; ------ Build started: Project: Complex plugin, Configuration: Debug Win32 ------ Linking... Creating library .\../Debug/complex_plugin.lib and object .\../Debug/complex_plugin.exp libRmath.a(mlutils.o) : warning LNK4217: locally defined symbol __iob imported in function _REprintf libRmath.a(dbeta.o) :

(1) ...need to speed up a monte-carlo sampling...any suggestions about how I can get R to use all 8 cores of a mac pro would be most useful and very appreciated... (2) spent the last few hours trying to get pnmath to compile under os- x 10.5.4... using gcc version 4.2.1 (Apple Inc. build 5553) as downloaded from CRAN, xcode 3.0... ...xcode 3.1 installed over top of above after

Hi, I am finding that I get quite different results when I interchange the following "equivalent" lines for sampling from a beta distribution in my r script. The rbeta line is correct judging by the summary statistics of the simulated values, while the qbeta line consistently leads to a higher mean simulated value. simulation <- rbeta(1, alpha, beta) simulation <- qbeta(runif(1),