Possible std.math.exp() bug

Don Clugston dac at nospam.com.au
Fri Apr 7 06:20:05 PDT 2006


anthony.difranco at yale.edu wrote:
>> Good to have another mathematics programmer around!
> I'm trying.  D has been very kind to me so far, with both reasonable semantics
> and reasonable efficiency, and now a reasonable community.
> 
>>> Also, is there a better way to do the ratio of two gammas than subtracting
>>> lgammas and exp at the end?
>> Do you mean, more accurate way? If the numbers are not too large, I 
>> don't think it matters much, even a simple division of the tgammas is 
>> probably OK, but lgamma() will save you from overflow problems.
>> If the arguments are large, the Stirling approximation is used, so there 
>> may be potential for greater accuracy. I'd be amazed if it actually 
>> mattered, though.
> 
> Actually, I should have said an as-overflow-resistant-as-possible way to do
> something like permutations (basically ratio of gammas).  Or maybe some useful
> scaling identity that doesn't wreck precision, though squeezing out the last few
> bits is not a concern.  My application (statistics related) is making even
> lgamma overflow as a matter of course.


For x > 1e10, it looks as though this is all lgamma() is doing:

const real LOGSQRT2PI  =  0.91893853320467274178L;

return ( x - 0.5L ) * log(x) - x + LOGSQRT2PI;

Disturbing. This doesn't look very accurate, although Stirling's 
approximation is probably very good by then.

So for large a, b
lgamma(a) - lgamma(b)
= a*(log(a)-1) - b*(log(b)-1) - 0.5 * (log(a) - log(b));
So overflows can be avoided quite easily ... but is any accuracy left?



More information about the Digitalmars-d-bugs mailing list