Displaying 13 results from an estimated 13 matches for "r_forceint".
2020 Jan 14
4
[R] choose(n, k) as n approaches k
...we should return 1, that we either return 0 (negative case) or n (positive case; because the n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1 or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce an integer, due to the
return R_IS_INT(n) ? R_forceint(r) : r;
part.
-pd
> On 14 Jan 2020, at 17:02 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>
> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>>>
>>> On...
2020 Jan 14
2
[R] choose(n, k) as n approaches k
...is less than 0, so we return 0. However, as you point out, 1 would be more reasonable and in accordance with the limit as n -> 4, e.g.
>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>> [1] -9.289025e-11
>> I guess that the fix could be as simple as replacing n by R_forceint(n) in the k = n - k step.
>
> I think that would break symmetry: you want choose(n, k) to equal choose(n, n-k) when n is very close to an integer. So I'd suggest the replacement whenever R_IS_INT(n) is true.
>
But choose() very deliberately ensures that k is integer, so choose(n,...
2020 Jan 15
1
[R] choose(n, k) as n approaches k
...1, that we either return 0 (negative case) or n (positive case; because the n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1 or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce an integer, due to the
>>
>> return R_IS_INT(n) ? R_forceint(r) : r;
>>
>> part.
>>
>> -pd
>>
>>
>>
>>> On 14 Jan 2020, at 17:02 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>>>
>>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>>> On 14 Jan 2020, at...
2020 Jan 14
1
[R] choose(n, k) as n approaches k
...o
n - k == -1e-7
which is less than 0, so we return 0. However, as you point out, 1 would be more reasonable and in accordance with the limit as n -> 4, e.g.
> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
[1] -9.289025e-11
I guess that the fix could be as simple as replacing n by R_forceint(n) in the k = n - k step.
-pd
> On 14 Jan 2020, at 00:33 , Wright, Erik Scott <ESWRIGHT at pitt.edu> wrote:
>
> This struck me as incorrect:
>
>> choose(3.999999, 4)
> [1] 0.9999979
>> choose(3.9999999, 4)
> [1] 0
>> choose(4, 4)
> [1] 1
>> c...
2020 Jan 14
0
[R] choose(n, k) as n approaches k
...return 1, that we either return 0 (negative case) or n (positive case; because the n(n-1)(n-2)... product has at least one factor). In the other cases, we get 1 or n(n-1)(n-2)...(n-k+1) which if n is near-integer gets rounded to produce an integer, due to the
>
> return R_IS_INT(n) ? R_forceint(r) : r;
>
> part.
>
> -pd
>
>
>
>> On 14 Jan 2020, at 17:02 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>>
>> On 14/01/2020 10:50 a.m., peter dalgaard wrote:
>>>> On 14 Jan 2020, at 16:21 , Duncan Murdoch <murdoch.duncan at...
2020 Jan 14
0
[R] choose(n, k) as n approaches k
...n 0, so we return 0. However, as you point out, 1 would be more reasonable and in accordance with the limit as n -> 4, e.g.
>>>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
>>> [1] -9.289025e-11
>>> I guess that the fix could be as simple as replacing n by R_forceint(n) in the k = n - k step.
>>
>> I think that would break symmetry: you want choose(n, k) to equal choose(n, n-k) when n is very close to an integer. So I'd suggest the replacement whenever R_IS_INT(n) is true.
>>
>
> But choose() very deliberately ensures that k is in...
2020 Jan 13
3
choose(n, k) as n approaches k
This struck me as incorrect:
> choose(3.999999, 4)
[1] 0.9999979
> choose(3.9999999, 4)
[1] 0
> choose(4, 4)
[1] 1
> choose(4.0000001, 4)
[1] 4
> choose(4.000001, 4)
[1] 1.000002
Should base::choose(n, k) check whether n is within machine precision of k and return 1?
Thanks,
Erik
***
sessionInfo()
R version 3.6.0 beta (2019-04-15 r76395)
Platform: x86_64-apple-darwin15.6.0
2020 Jan 13
3
choose(n, k) as n approaches k
This struck me as incorrect:
> choose(3.999999, 4)
[1] 0.9999979
> choose(3.9999999, 4)
[1] 0
> choose(4, 4)
[1] 1
> choose(4.0000001, 4)
[1] 4
> choose(4.000001, 4)
[1] 1.000002
Should base::choose(n, k) check whether n is within machine precision of k and return 1?
Thanks,
Erik
***
sessionInfo()
R version 3.6.0 beta (2019-04-15 r76395)
Platform: x86_64-apple-darwin15.6.0
2020 Aug 10
2
qnbinom with small size is slow
....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...
2020 Jan 14
0
[R] choose(n, k) as n approaches k
...is less than 0, so we return 0. However, as you point out, 1 would be more reasonable and in accordance with the limit as n -> 4, e.g.
>
>> factorial(4 - 1e-10)/factorial(1e-10)/factorial(4) -1
> [1] -9.289025e-11
>
> I guess that the fix could be as simple as replacing n by R_forceint(n) in the k = n - k step.
I think that would break symmetry: you want choose(n, k) to equal
choose(n, n-k) when n is very close to an integer. So I'd suggest the
replacement whenever R_IS_INT(n) is true.
Duncan Murdoch
>
> -pd
>
>
>
>> On 14 Jan 2020, at 00:33 ,...
2020 Aug 20
0
qnbinom with small size is slow
...nom.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 exist...
2020 Aug 21
1
qnbinom with small size is slow
...nom.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 exist...
2020 Aug 07
2
qnbinom with small size is slow
Hi all,
I recently noticed that `qnbinom()` can take a long time to calculate
a result if the `size` argument is very small.
For example
qnbinom(0.5, mu = 3, size = 1e-10)
takes ~30 seconds on my computer.
I used gdb to step through the qnbinom.c implementation and noticed
that in line 106
(https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qnbinom.c#L106)