------- Comment #20 from vincent at vinc17 dot org 2006-10-28 14:05 ------- (In reply to comment #19) > The documenation in MPFR says: > -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND) > Set ROP to the value of the Gamma function on OP, and its > logarithm respectively, rounded in the direction RND. When OP is > a negative integer, NaN is returned. > > It only talked about negative integers,
AFAIK, this was mainly for Gamma(negative integer). But this is also true for lngamma(negative integer). But the point is that if gamma(x) is negative, then lngamma(x) is NaN since the logarithm of a negative value is NaN. But that's why the C standard defines lgamma as log|gamma(x)| instead of log(gamma(x)). > and I glossed over the fact that it > left out the absolute value that C does. So it was pilot error, but I think a > clarification would help. Many times in the docs MPFR takes pains to follow > the C99 standard, e.g. the inputs to atan2 or pow. Where you deviate from it > should also be noted. I agree. And I think that none of the MPFR developers were aware of this problem (I didn't notice the difference when I was looking for C functions that were missing in MPFR). I posted a mail about that on the MPFR mailing-list. > Or you could consider it a bug and fix it. :-) I think this is the best solution, in particular because this would change only NaN values. > Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right? Probably not a good idea, because I think that mpfr_gamma may overflow, though the final result may be in the double-precision range. > Glad to hear a new version is coming out. If you make a prerelease tarball > available somewhere I'd like to try it with mainline GCC. OK, I hope I won't forget to announce it in the gcc dev mailing-list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
