------- Comment #19 from ghazi at gcc dot gnu dot org 2006-10-28 13:28 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Yes, I can reproduce the NaN. In fact, any negative value
> > gives a NaN.
> Not any negative value, but in lngamma.c:
> /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */
> probably because the gamma value is negative. This is because MPFR defines
> lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I
> wonder if this should be regarded as a bug or if a new function (say,
> mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0).
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, 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.
Or you could consider it a bug and fix it. :-)
Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right?
> Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite
> loop in the 2.2 branch. This problem is now detected in the trunk, and until
> this is completely fixed, a NaN is returned with the MPFR erange flag set.
> This
> should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will
> come several days after that).
If it returns NaN for now that's fine since GCC avoids any transformation that
returns NaN or Inf.
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
