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

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
Owner

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 distributions.py-- I'll fix them as I find them.

Member

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

Contributor

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

Member

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

Contributor

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?

Owner

pv commented May 1, 2011

Pulled.

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

Member

josef-pkt commented May 1, 2011

Pauli,

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 - scipy.org 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…
…urces.

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