similar to: phyper accuracy and efficiency (PR#6772)

Dear R-users, In R 2.5.1 on Windows XP, SP2 the call to phyper(0,0,74,3,lower.tail=FALSE) returns -4.195862e-17. This does not happen with R2.5.1 on Linux, 0 is returned. Is this a bug (and should be reported as such), since phyper should not return negative values, or is this considered as one of the annoyances of finite precision arithmetic. I tend to think of this as a bug since it breaks the

Dear All I have a question about the hypergeomteric distribution. Example 1: I have a universe of 6187 objects, and 164 have a particular attribute, therefore 6187-164 do not have that attribute. I sample 249 of those objects, and find that 19 have that attribute. I get a p-value here (looking at just over-representation): phyper(19, 164, 6187-164, 249, lower.tail=FALSE) [1] 7.816235e-06

Hi, I am attempting to use phyper to test the significance of two overlapping lists. I keep getting a zero and wondered if that was determining non-significance of my overlap or a p-value too small to calculate? overlap = 524 lista = 2784 totalpop = 54675 listb = 1296 phyper(overlap, lista, totalpop, listb,lower.tail = FALSE, log.p=F) [1] 0 If I plug in some different values I get a p-value but

Full_Name: Utz J. Pape Version: 2.2.0 OS: linux Submission from: (NULL) (141.14.23.12) If I use phyper and set parameter x equal to k (meaning that all balls I draw are white) phyper returns 1 which is not (always) correct: pape at xxx:~> R2.2.0 --vanilla R : Copyright 2005, The R Foundation for Statistical Computing Version 2.2.0 (2005-10-06 r35749) ISBN 3-900051-07-0 R is free software

Last night I sent the bug report below to r-help. I have since then looked at dhyper.c and found: if (NR < 0 || NB < 0 || n <= 0 || n > N) DOMAIN_ERROR; I changed 'n <= 0' to 'n < 0' and then dhyper worked as I wanted. Am I introducing some potentially dangerous behaviour by this change? Goran

Aloha all, I know too little about what I'm about to write and hope I'm not wasting your time. For a class I'm teaching in archaeological data analysis, I'm trying to put together a routine that calculates the so-called Petersen index and, especially, confidence intervals for the index. This was introduced to archaeologists by N.R.J. Fieller and A. Turner in an article

Dear R Users, I employed the phyper() function to estimate the likelihood that the number of genes overlapping between 2 different lists of genes is due to chance. This appears to work appropriately. Now i want to try this with 3 lists of genes which phyper() does not appear to support. Some googling suggests i can utilize the Multivariate hypergeometric distribution to achieve this. eg.:

Hi Martin, thanks for verifying. I agree that the Cornish-Fisher seems to struggle with the small size parameters, but I also don't have a good idea how to replace it. But I think fixing do_search() is possible: I think the problem is that when searching to the left y is decremented only if `pnbinom(y - incr, n, pr, /*l._t.*/TRUE, /*log_p*/FALSE)) < p` is FALSE. I think the solution is

Full_Name: Morten Welinder Version: 1.5.1 OS: Solaris Submission from: (NULL) (65.213.85.136) I was having problems with qgamma's precision in the sense that pgamma(qpgamma(x)) was not as close to the identity function as I would like. I was seeing relative errors with random input of about 1e-8. This fits nicely with the code'd EPS2 value of 5e-7. To solve this I added a newton step

Here's a contribution from Ian Smith that got bounced from the list. -------- Original Message -------- Subject: Re: [Rd] pt inaccurate when x is close to 0 (PR#9945) Date: Thu, 11 Oct 2007 06:02:43 -0400 From: iandjmsmith at aol.com To: murdoch at stats.uwo.ca Duncan, I tried sending the rest of this to R-devel but it was rejected as spam, hence the personal e-mail. R calculates the pt

Full_Name: M. Welinder Version: 1.8.1 OS: Solaris Submission from: (NULL) (65.213.85.227) Currently R has... #define R_D_Lval(p) (lower_tail ? (p) : (1 - (p))) /* p */ #define R_D_val(x) (log_p ? log(x) : (x)) /* x in pF(x,..) */ #define R_DT_val(x) R_D_val(R_D_Lval(x)) /* x in pF */ ...which is sub-optimal in the lower_tail==FALSE && log_p==TRUE case. Something like this ought

Full_Name: Morten Welinder Version: 2.1.0 OS: src only Submission from: (NULL) (216.223.241.212) Now that pcauchy has been fixed, it is becoming clear that qcauchy suffers from the same problems. qcauchy(pcauchy(1e100,0,1,FALSE,TRUE),0,1,FALSE,TRUE) should yield 1e100 back, but I get 1.633178e+16. The code below does much better. Notes: 1. p need not be finite. -Inf is ok in the log_p

Full_Name: Mikael Weigelt Version: 2.0 OS: windows Submission from: (NULL) (207.171.180.101) The calculation of the qpois attempts to use the Cornish-Fisher expansion as a starting approximation. The definition of the expansion is incorrect. However, since this approximation just gives an initial solution, the end result of the function is still correct. To fix the approximation, in the

>>>>> Constantin Ahlmann-Eltze via R-devel >>>>> on Mon, 10 Aug 2020 10:05:36 +0200 writes: > Thanks Ben for verifying the issue. It is always reassuring to hear > when others can reproduce the problem. > I wrote a small patch that fixes the issue > (https://github.com/r-devel/r-svn/pull/11): > diff --git

Kenneth Cabrera <krcabrer@epm.net.co> writes: > Hello developers and users: > > My system fails (the computer freezes) when I use the ncp parameter, > with the lower.tail=FALSE option in the qchisq function. > > qchisq(0.025,31,ncp=1,lower.tail=FALSE) Yup, that's a bug. We have in pnchisq.c 48 for (ux = 1.0; pnchisq(ux, n, lambda, lower_tail, log_p) <

>>>>> "PD" == p dalgaard <p.dalgaard@biostat.ku.dk> writes: PD> Kenneth Cabrera <krcabrer@epm.net.co> writes: >> Hello developers and users: >> >> My system fails (the computer freezes) when I use the ncp parameter, >> with the lower.tail=FALSE option in the qchisq function. >> >>

Thanks Ben for verifying the issue. It is always reassuring to hear when others can reproduce the problem. I wrote a small patch that fixes the issue (https://github.com/r-devel/r-svn/pull/11): diff --git a/src/nmath/qnbinom.c b/src/nmath/qnbinom.c index b313ce56b2..d2e8d98759 100644 --- a/src/nmath/qnbinom.c +++ b/src/nmath/qnbinom.c @@ -104,6 +104,7 @@ double qnbinom(double p, double size,

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

Full_Name: Morten Welinder Version: snapshot OS: Submission from: (NULL) (65.213.85.218) This should fix the remaining two 1-p cancellation issues. double l_rt = log1p (-p) * (x + 1); if (log_p) return R_DT_Clog (l_rt); else return lower_tail ? -expm1 (l_rt) : exp (l_rt);

About April 25th, there had been some changes within R-devel's src/nmath/pnbeta.c (and probably some other relevant places) and now building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and math/R-devel (selfmade forked port from math/R) fails like this: [..snip..] mkdir /usr/ports/math/R-devel/work/R-devel/bin/exec gcc46 -std=gnu99 -I../../src/extra -I. -I../../src/include