similar to: qnbinom with small size is slow

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,

?? I can reproduce this on R Under development (unstable) (2020-07-24 r78910) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Pop!_OS 18.04 LTS ? In my opinion this is worth reporting, but discussing it here first was a good idea.? Many more people read this list than watch the bug tracker, so it will get more attention here; once the excitement has died down here (which might be

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

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

(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

Dear Experts, Probably trivial, but I am struggling to get what I want: I need to know how the number of required trials to get a certain number of successes. By example: How many trials do I need to have 98% probability of 50 successes, when the a priory probability is 0.1 per trial. The Negative binomial function may do the job (not sure): NegBinomial {stats} The Negative Binomial

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

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

On 23/02/05 I suggested that given R had included TOMS 708 to correct for t= he=20 poor performance of pbeta, TOMS 654 should be included to fix all the pgamm= a=20 problems. I was slightly surprised to find Morten's code had been included= =20 instead 2 days later. I noticed but did not worry that the reference to me = had=20 been removed.=20 The derivation of the asymptotic expansion for

Dear list, I ran into a strange behaviour of the pnbinom function - or maybe I just made a stupid mistake. First thing is that pnbinom seems to be very slow. The other - more interesting one - is that I get two different curves when I plot the estimated density and the density given by pnbinom. Shouldn't it be the same? This is only the case, I think, if I use the parameter size = 1. I

Hi there I'm trying to find the mle fo a multinomial model ->*L(N,h,S?x)*. There is only *N* I want to estimate, which is used in the number of successes for the last cell probability. These successes are given by: p^(N-x1-x2-...xi) All the other parameters (i.e. h and S) I know from somewhere else. Here is what I've tried to do so far for a imaginary data set:

Dear colleagues/contributors, I'd be pleased if someone could provide insights on how to plot impulse response functions in a format that can easily be copied in a word document just as plotting time-series of variables. I had followed the outline suggested by Benhard Pfaff [see http://127.0.0.1:17693/library/vars/html/irf.html] but I am unable to get the impulse response functions in a

On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> wrote: > I will say I'm not a huge fan of adding even more names for things in > this fairly core/common use case (now we'll have even more vector > names to pick from) - can we use default template arguments so we can > write SmallVector<T> instead of SmallVector<T, N> and would that >

On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> I will say I'm not a huge fan of adding even more names for things in > >> this fairly

We've pretty happy now with a patch that adds two wrappers around SmallVector that make it 1) more convenient to use and 2) will tend to mitigate misuse of SmallVector. We think it's ready for wider discussion: https://reviews.llvm.org/D90884 SVec<T> is a convenience alias for SmallVector<T, N> with N chosen automatically to keep its size under 64 Bytes (that heuristic is easy

On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > > > > > On Mon, Nov 16, 2020 at 2:12 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> On Mon, Nov 16, 2020 at 1:55 PM Mehdi AMINI <joker.eph at

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

Try changing your method to "ML" and try again. I tried the run the first example from the documentation and it failed with the same error. Changing the estimation method to ML worked. @List: Can anyone else verify the error I got? I literally ran the following two lines interactively from the example for goodfit: dummy <- rnbinom(200, size = 1.5, prob = 0.8) gf <- goodfit(dummy,