From owner-freebsd-current@FreeBSD.ORG Tue May 29 03:03:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9099106564A for ; Tue, 29 May 2012 03:03:50 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id AAFF58FC14 for ; Tue, 29 May 2012 03:03:50 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q4T33hXZ060897; Mon, 28 May 2012 22:03:44 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FC43C8F.5090509@missouri.edu> Date: Mon, 28 May 2012 22:03:43 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Steve Kargl References: <4FC36FE1.9080908@gwdg.de> <4FC38B81.6000302@gwdg.de> <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> In-Reply-To: <20120529000756.GA77386@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 03:03:50 -0000 On 05/28/2012 07:07 PM, Steve Kargl wrote: > On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote: >> On 05/28/2012 06:30 PM, Steve Kargl wrote: >> >>> >>> > From clog.c in http://www.netlib.org/cephes/c9x-complex >>> >>> double complex >>> ccosh (z) >>> double complex z; >>> { >>> double complex w; >>> double x, y; >>> >>> x = creal(z); >>> y = cimag(z); >>> w = cosh (x) * cos (y) + (sinh (x) * sin (y)) * I; >>> return (w); >>> } >>> >>> See math_private.h about the above. >>> >> >> I looked in math_private.h - I presume you meant >> lib/msun/src/math_private.h. I wasn't able to find anything about ccosh >> there. >> >> I think that for a rough and ready ccosh, this is high enough quality >> for a math/cephes port. > > That's the problem. It is not acceptable (imo). The comment in > math_private.h that is relevant is > > /* > * Inline functions that can be used to construct complex values. > * > * The C99 standard intends x+I*y to be used for this, but x+I*y is > * currently unusable in general since gcc introduces many overflow, > * underflow, sign and efficiency bugs by rewriting I*y as > * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product. > * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted > * to -0.0+I*0.0. > */ > > Those wrong +-0 mean you may up end up on the worng riemann sheet, > and that NaN propagates. > OK, I agree with you that gcc fails to be C99 compliant. But I disagree with you that this is a big deal. 1. By being so picky about being so precise, FreeBSD is behind the time line in rolling out a usable set of C99 functions. The compilers and operating systems have many bugs, and if we waited until we were totally sure that all the bugs were gone, we wouldn't have any operating system to work with at all. Why be more picky with floating point arithmetic than the other aspects of FreeBSD? 2. If I was really worried about being on the correct Riemann sheet, I would code very, very carefully, and not rely on numerical accuracy of any kind of floating point calculation. There is a certain mathematical inconsistency in introducing 0, -0 and Inf+I*Inf, and the number of times programmers really want a very specific kind of behavior for exceptions is so rare that they are better off writing their own wrapper code than relying on any library functions. (For example, is there a difference between 0 and +0? If not, does -(0) compute to 0 or -0? I can see circumstances where I sometimes want one, and sometimes the other.) 3. But to counter my own argument, it highly bothers me that in C that "(-5)%3" evaluates to "-2" and not to "1". That bug^H^H^H feature has truly bitten me. And I have had lengthy arguments online with some C experts as to why "1" should be the correct answer, without being able to convince them. If it were up to me, the whole of the C standard would be scrapped, and rewritten with everything exactly the same except for this one thing. But to those I argued with, I seem just as picky as you seem when you insist that 0 and -0 are different. So what do I do? I live with it, just like we all live in an imperfect world. If I had a choice between correcting the C standard for "%" or solving world hunger, I would definitely settle for the second. And maybe the C programming language, for all its imperfections, has helped push frontiers of technology sufficiently that someone is less hungry than they would have otherwise been. And if those resources used to feed people had been redirected to fix the C standard, then maybe a few more people would be hungry. In the end, I do think it is good to ultimately settle on good C99 compliant code. But having something intermediate that mostly works is better than nothing. Especially if it exists only in the ports, and not in the base code.