Re: [Rd] qnbinom with small size is slow
> 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 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, double prob, > int lower_tail, int log_p) > /* y := approx.value (Cornish-Fisher expansion) : */ > z = qnorm(p, 0., 1., /*lower_tail*/TRUE, /*log_p*/FALSE); > y = R_forceint(mu + sigma * (z + gamma * (z*z - 1) / 6)); > +y = fmax2(0.0, y); > z = pnbinom(y, size, prob, /*lower_tail*/TRUE, /*log_p*/FALSE); > I used the https://github.com/r-devel/r-svn repo and its continuous > integration tools to check that it doesn't break any existing tests: > https://github.com/r-devel/r-svn/actions/runs/201327042 > I have also requested a Bugzilla-account, but haven't heard anything back yet. > Best, > Constantin Thank you for the report, and Ben for his experiment. And, indeed in this case, this returns 0 much more quickly. Note that this could be even much more quickly: The Cornish-Fisher expansion is not really of much use here, ... and quick check would just see that pnbinom(0, size, prob) > Note however, that in other cases, results for small 'size' are *still* not good (and *not* influenced by your patch !!), e.g., ## Other examples, not giving 0, are fast already but *in*accurate: qnbinom(., mu=3, size=1e-4) ## [1] 8044 ## but str(ur1 <- uniroot(function(q) pnbinom(q, mu=3, size=1e-4) - 0., c(7000,8000))) ## List of 5 ## $ root : num 7942 ## $ f.root: num 1.52e-09 ## $ iter : int 18 ## $ init.it : int NA ## $ estim.prec: num 6.49e-05 ## and this of course does not change when asking for more precision : str(ur2 <- uniroot(function(q) pnbinom(q, mu=3, size=1e-4) - 0., c(7000,8000), tol=1e-12)) ## List of 5 ## $ root : num 7942 <<< correct is 7942, not 8044 !!! ## $ f.root: num 1.52e-09 ## $ iter : int 47 ## $ init.it : int NA ## $ estim.prec: num 7.28e-12 -- so, in principle the C-internal search() function really should be improved for such ( somewhat extreme!! ) cases. or ... ?? ... a different approximation should be used for such extreme small 'size' (and prob := size/(size+mu) ) ... Martin Maechler ETH Zurich and R Core team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] utils::isS3stdGeneric chokes on primitives and identity
> Gabriel Becker writes:
> I added that so I can look at the proposed fix and put it or something
> similar in bugzilla for review final review.
> Apologies for the oversight.
Fixed now with
-while(as.character(bdexpr[[1L]]) == "{")
+while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{"))
(the suggested fix does not work on things like
foo <- function(x) {{ x }}
...)
Best
-k
> ~G
> On Wed, Aug 19, 2020 at 3:40 PM Antoine Fabri
> wrote:
>> Dear R-devel,
>>
>> utils::isS3stdGeneric tries to subset the body of the function it's fed,
>> primitives don't like that because they don't have a body, identity doesn't
>> like it either because it's body is a symbol.
>>
>> According to the doc, any function is a legal input.
>>
>> See below:
>>
>> identity
>> #> function (x)
>> #> x
>> #>
>> #>
>>
>> max
>> #> function (..., na.rm = FALSE) .Primitive("max")
>>
>> isS3stdGeneric(identity)
>> #> Error in bdexpr[[1L]]: objet de type 'symbol' non indiçable
>>
>> isS3stdGeneric(max)
>> #> Error in while (as.character(bdexpr[[1L]]) == "{") bdexpr <-
>> bdexpr[[2L]]: l'argument est de longueur nulle
>>
>> Here is a simple fix :
>>
>> isS3stdGeneric <- function(f) {
>> {
>> bdexpr <- body(f)
>> if(is.null(bdexpr) || !is.call(bdexpr)) return(FALSE)
>> while (as.character(bdexpr[[1L]]) == "{") bdexpr <- bdexpr[[2L]]
>> ret <- is.call(bdexpr) && identical(bdexpr[[1L]], as.name
>> ("UseMethod"))
>> if (ret)
>> names(ret) <- bdexpr[[2L]]
>> ret
>> }
>> }
>>
>> isS3stdGeneric(identity)
>> #> [1] FALSE
>> isS3stdGeneric(max)
>> #> [1] FALSE
>>
>> Best,
>>
>> Antoine
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> [[alternative HTML version deleted]]
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stale link from ?check to R Internals
> Duncan Murdoch writes:
> On 19/08/2020 12:26 p.m., Toby Hocking wrote:
>> Hi the reference to R Internals
>> https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools
>> in ?check (PkgUtils.Rd in utils package) is stale. Here is my proposed
>> patch (use named reference rather than numeric reference to avoid any
>> similar broken links in the future).
> Just to be clear: you're giving the current URL, the problem is it's
> called "Chapter 6".
Fixed now.
Best
-k
> Duncan Murdoch
>>
>> Index: src/library/utils/man/PkgUtils.Rd
>> ===
>> --- src/library/utils/man/PkgUtils.Rd (revision 79049)
>> +++ src/library/utils/man/PkgUtils.Rd (working copy)
>> @@ -40,7 +40,7 @@
>> set by environment variables \env{_R_BUILD_RESAVE_DATA_} and
>> \env{_R_BUILD_COMPACT_VIGNETTES_}: see \sQuote{Writing \R Extensions}.
>> Many of the checks in \command{R CMD check} can be turned off or on by
>> - environment variables: see Chapter 6 of the \sQuote{R Internals} manual.
>> + environment variables: see Chapter "Tools" of the \sQuote{R Internals}
>> manual.
>>
>> By default \command{R CMD build} uses the \code{"internal"} option to
>> \code{\link{tar}} to prepare the tarball. An external \command{tar}
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
