similar to: Buglet in qbeta?

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,

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.

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

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

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

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

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

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

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.

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

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

Hello R-Help, I ran some analysis and were hit with some low Z-score. I tried to convert it to a p-value, however, it seems like the ceiling is around 1e-16. > 1-pnorm(8) [1] 6.661338e-16 > 1-pnorm(9) [1] 0 Do you have any suggestion how I can display a very low p-value in the form of scientific number format? Thank you very much. Regards, Bhoom [[alternative HTML version deleted]]

Dear all, I'm a bit concerned about underflow problems. Such problems typically occur when two almost equal numbers are subtracted. I was wondering if R has any mechanisms for warning users about potential problems, or if any policy has been developed? To check, I just did: > 1.0000000000000001 - 1 [1] 0 > 1.000000000000001 - 1 [1] 1.110223e-15 > 1.00000000000001 - 1 [1]

I compiled R 2.1.0 under Windows XP SP2 as a preliminary to rebuilding a custom package for use with R 2.1.0. The compile completed successfully, and I was able to run demo(graphics) successfully. But make check and make check-recommended fail. > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 1.0 year 2005

Dear all, I have come across a very confusing matter regarding dist() supplied by the amap package: --- m is just a test matrix > library(amap) Loading required package: mva Warning message: package 'mva' has been merged into 'stats' > m a b c aa 0.1 0.2 0.3 bb 2.0 3.0 4.0 cc 2.0 4.0 6.0 dd 0.3 0.2 0.1 > ds<-dist(m,method="pearson") >

[I thought I'd submitted this bug report some time ago, but it's never showed up on the bug tracking system, so I'm submitting again.] qr.solve() gives incorrect results when dealing with complex matrices or with qr objects that have been computed with LAPACK=TRUE, whenever the b argument has more than one column. This bug flows from qr.coef(), which has a similar problem. I believe

Dear all, Sorry for bringing up an old issue: >pexp(50, 0.5) [1] 1 In some cases, pexp() gives CDF=1. I read some discussion in 2002 saying it has been patched. However it's not working in "R2.4.1Patched". Could anyone help me out? Thanks a lot, Jeann _________________________________________________________________ Fine Dining & Fancy Food. Check Out This

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1660387551-1458482416-1249639718=:2997 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <Pine.LNX.4.64.0908071039211.2997 at parser.ilovebacon.org> Hello, There appears to be a bug in the nlm function, which I

I've now done two rebuilds of R-1.7.0 on NetBSD 1.6, one with the --without-zlib configure option, and one without. Both builds use the recently-installed gcc-3.2.3 compiler. As before, the one built normally gets a segment violation, whereas the one built with the --without-zlib option works. The odd thing is that neither uses shared libraries for zlib: % ldd /usr/local/lib/R/bin/R.bin