[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: Problems with gamma, lgamma, and alternatives

**From**: |
Przemek Klosowski |

**Subject**: |
Re: Problems with gamma, lgamma, and alternatives |

**Date**: |
Tue, 25 Mar 2003 15:31:54 -0500 (EST) |

octave:1> gamma(1000)
...
SLATEC DGAMMA X SO BIG GAMMA OVERF 3 2 1
These usually occur during intermediate iterations of a minimization
routine,
where it's difficult to control the value that will be passed to gamma. The
It's a tough one: on one hand, gamma(171) is largest double precision
representable integer argument (~7.2574e+306), gamma(1000) would be,
oh, about 999!, or ~4.02e+2564. If you are venturing there during a search
you are hosed---there is no numerical accuracy there at all.
I could see two approaches: one is to wrap gamma in an octave function
that returns Inf if the argument exceeds 171, and calls gamma
otherwise. This way, perhaps the minimization will come back from
those regions---Inf compares larger than any number---but there are no
guarantees.
The other approach is to penalize the objective function for entering
the forbidden regions directly:
if (param3 >= 171); chisq += 1e6; endif
-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html
-------------------------------------------------------------