similar to: qbeta hang (PR#2894)

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

>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'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

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.

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

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

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

(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

I came across the message below and decided to respond. I don't use R but I do use other FSF products and I am a believer in making high quality software freely available, particularly for basic mathematical and statistical functions. I can thorougly recommend TOMS Algorithm 708 but I believe there are a couple of problems from you point of view. Firstly there may be restrictions on how it

Suppose i want to compute a 95% highest density for a beta distribution beta(a,b) the two end points x1 and x2 shoudl satisfy the following two equations: pbeta(x1,a,b)-pbeta(x2,a,b)=95% dbeta(x1,a,b)=dbeta(x2,a,b) Is there any fast way to compute x1 and x2 in R? [[alternative HTML version deleted]]

There is a problem with `rpois'. It does seem to take care about the order of the arguments. This is an example: > rpois(n=1,lambda=2) [1] 3 > rpois(lambda=2,n=1) [1] 2 0 It obviously uses the first argument as the number of samples to be drawn, which is wrong. I used Version 0.49 Beta (April 23, 1997). Fredrik

There is a problem with `rpois'. It does seem to take care about the order of the arguments. This is an example: > rpois(n=1,lambda=2) [1] 3 > rpois(lambda=2,n=1) [1] 2 0 It obviously uses the first argument as the number of samples to be drawn, which is wrong. I used Version 0.49 Beta (April 23, 1997). Fredrik

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

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

hi, i'm new to R and i'm trying to port a quattro pro spreadsheet into R. spreadsheets have optional lower and upper limit parameters on the beta distribution function. i would like to know how to incorporate this with R's pbeta function. thanks in advance, mara. ____________________________________________________________________________________ Park yourself in front of a

>>>>> 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,

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

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: ---------------------------------------------------------------------- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include