Fixing a special.gamma overrun in gamma.pdf #5

wants to merge 1 commit into


None yet
3 participants

pv commented Mar 10, 2011

Copied from scipy/scipy-svn#5

wesm opened this pull request February 21, 2011
Fixing a special.gamma overrun in gamma.pdf
There are more to be found in I'll fix them as I find them.


josef-pkt commented Mar 22, 2011

(a-1)*log(x) - x - gamln(a) breaks if a=1 and x=0, corner case that is not ruled out.

the change in this pull request is good, however that it also propagates the 0log0 error from _logpdf to _pdf.

overall it looks like the change to _logpdf introduced several cases of possible 0*log(0) errors


wesm commented Apr 10, 2011

Likely no choice here but to check if x != 0? I'm not sure what's the best way to add a commit to this pull request


josef-pkt commented Apr 10, 2011

I would just pull this into scipy, and create separate pull requests or commits for the 0*log0 fixes

(Of all possible solution that we use for 0log0 I haven't found one I'm really happy with.)


wesm commented May 1, 2011

Why don't we do that and close this pull request, we should separately make a pass through and fix the 0*log(0) issues as you mention. @pv is that OK with you?


pv commented May 1, 2011


Personally, I'd just make a separate ylogx function for y*log(x) with appropriately defined y -> 0 limit and use it everywhere where needed.

@pv pv closed this May 1, 2011


josef-pkt commented May 1, 2011


having a correct xlogy function available would solve the problem and would be useful in many cases in scipy and statsmodels. I proposed it once on the numpy mailing list (Jan 14) but without reponse.

rgommers added a commit that referenced this pull request Jun 2, 2012

Merge pull request #5 from scottza/maintainers
Maintainers doc update - website related text

rgommers added a commit that referenced this pull request Aug 21, 2013

BLD: fix MinGW Windows build issue by splitting linalg.interpolate so…

Type of errors that this fixes::

    Argument #5 (named `ifac') of `zfftb1' is one type at (2) but is some
    other type at (1) [info -f g77 M GLOBALS]

Warning shows up with gfortran as::

    Warning: Type mismatch in argument 'ifac' at (1); passed REAL(8) to INTEGER(4)

Closes gh-2709.

WarrenWeckesser pushed a commit that referenced this pull request Jan 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment