similar to: less precision, please!

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

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.

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

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

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

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?

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

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

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

(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, Using the fast=F option, sqlSave saves without matching column names. It looks like a bug to me.......... Here's a simple (artificial) example. ----------------------------------------- Create a dataframe and save it to a database table "test" as follows: df <- data.frame(T=1, S=10) sqlSave(channel, df, "test", rownames=F) The table now looks like T S 1 10 If

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

Hi all, Are there any small patches or further testing that any R-core members would like help with in the preparation to 4.0.0? Sadly @Martin Maechler <maechler at stat.math.ethz.ch> I don't have the numerical optimization chops to be any help with qbeta, sorry. But if there's anything else, small private wishlist items or things that could use another ste of eyes or some testing