New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The binomial implementation does a quotient of gamma values, which is wrong #12448
Comments
Attachment: bug_12448.patch.gz Patch to make the situation better |
comment:2
I'm not too happy with my patch after all: binomial(float(1001),float(1)) is still a nan ; I should make it a little smarter. |
comment:3
The current code (not your patch) looks overly complicated for a binomial function. What is the definition being used? Can't it simply be defined as (assuming
Doesn't this hold irrespective of whether
Am I missing some definition of the binomial here, which contains the gamma function necessarily? |
comment:4
There are several things to say about the matter:
|
comment:5
The case of m noninteger is already properly handled in the code. The code checks whether either m or x-m is an integer and only then proceeds. That's why I think calling the gamma function is not necessary. |
This comment has been minimized.
This comment has been minimized.
comment:6
Added a patch which uses pari now, as was indicated as a future fix in a comment. This speeds up all the floating point binomials by about a factor of 5, and fixes the nan that was being returned from large floats. Needs review now :) Patchbot apply trac_12448-fix_binomial.patch |
comment:7
Patching and compiling are ok on amd64 and armv7l. On amd64, doctesting is ok, but on arm, the line 3143: |
comment:8
Can you check which part raises the pari error? Is it |
Work Issues: pari error on arm |
comment:10
It's the .binomial part which raises an error : binomial(RR(1140000.78), 23310031) works, but binomial(RR(1140000.78), 23310032) raises the error (dichotomy). |
comment:11
Replying to @SnarkBoojum:
So, it seems to be some overflow problems in arm? Should we just change the example
to the one below which works on arm? After all, what this is testing is that the binomial is fast, which is well tested even with something that is half the size of the previous one
Or, does this point to some problem in pari? |
comment:12
Well, if some piece of code works on a platform but doesn't on another, then there's obviously something to investigate. Is it easy to write a C pari-using test case? I'd gladly give it a try. |
comment:13
I would put this problem on sage-devel, if you agree. I don't know pari and neither can I fix architecture specific idiosyncrasies. |
comment:14
According to sage-devel, indeed the doctest should be modified so it works on both 64 bits and 32 bits architectures. |
Reviewer: Julien Puydt |
comment:15
Thanks for following up in sage-devel. I have updated the patch with a smaller number. Patchbot apply trac_12448-fix_binomial.patch |
Author: Punarbasu Purkayastha |
Changed work issues from pari error on arm to none |
Work Issues: fix binomial(1000,1001) |
comment:16
Oops. I just found a failing case - the first example. |
Attachment: trac_12448-fix_binomial.patch.gz Apply to sage/devel |
comment:17
Should be fixed now. Patchbot apply trac_12448-fix_binomial.patch |
Changed work issues from fix binomial(1000,1001) to none |
comment:18
The new patch applies, compiles and passes all doctests in arith.py on armv7l and amd64. |
Merged: sage-5.7.beta4 |
There are special formulas to apply for quotients of gamma values, since those quotients can be pretty reasonable even though the numerator and denominator are too big, for example:
and:
Apply to sage/devel
Component: basic arithmetic
Author: Punarbasu Purkayastha
Reviewer: Julien Puydt
Merged: sage-5.7.beta4
Issue created by migration from https://trac.sagemath.org/ticket/12448
The text was updated successfully, but these errors were encountered: