From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17521 invoked by alias); 28 Oct 2006 14:06:03 -0000 Received: (qmail 17458 invoked by uid 48); 28 Oct 2006 14:05:52 -0000 Date: Sat, 28 Oct 2006 14:06:00 -0000 Message-ID: <20061028140552.17457.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "vincent at vinc17 dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg02395.txt.bz2 List-Id: ------- 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