From owner-freebsd-current@FreeBSD.ORG Wed Jul 25 17:00:13 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 C2456106566C; Wed, 25 Jul 2012 17:00:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9A02F8FC14; Wed, 25 Jul 2012 17:00:10 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6PH04VM072513; Wed, 25 Jul 2012 10:00:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6PH04cn072512; Wed, 25 Jul 2012 10:00:04 -0700 (PDT) (envelope-from sgk) Date: Wed, 25 Jul 2012 10:00:04 -0700 From: Steve Kargl To: Rainer Hurling Message-ID: <20120725170004.GA72338@troutmask.apl.washington.edu> References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <50101EDE.6030509@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50101EDE.6030509@gwdg.de> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.org, Bruce Evans 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: Wed, 25 Jul 2012 17:00:14 -0000 On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote: > > Many thanks to you three for implementing expl() with r238722 and r238724. > > I am not a C programmer, but would like to ask if the following example > is correct and suituable as a minimalistic test of this new C99 function? > It's not clear to me what you mean by test. If expl() is not available in libm, then linking the code would fail. So, testing for the existence of expl() (for example, in a configure script) is as simple as #include long double func(long double x) { return (expl(x)); } > //----------------------------------- > #include > #include > > int main(void) > { > double c = 2.0; > long double d = 2.0; > > double e = exp(c); > long double f = expl(d); > > printf("exp(%f) is %.*f\n", c, 90, e); > printf("expl(%Lf) is %.*Lf\n", d, 90, f); If you mean testing that the output is correct, then asking for 90 digits is of little use. The following is sufficient (and my actually produce a digit or two more than is available in number) troutmask:fvwm:kargl[203] diff -u a.c.orig a.c --- a.c.orig 2012-07-25 09:38:31.000000000 -0700 +++ a.c 2012-07-25 09:40:36.000000000 -0700 @@ -1,5 +1,6 @@ #include #include +#include int main(void) { @@ -9,8 +10,8 @@ double e = exp(c); long double f = expl(d); - printf("exp(%f) is %.*f\n", c, 90, e); - printf("expl(%Lf) is %.*Lf\n", d, 90, f); + printf("exp(%f) is %.*f\n", c, DBL_DIG+2, e); + printf("expl(%Lf) is %.*Lf\n", d, LDBL_DIG+2, f); return 0; } > > return 0; > } > //----------------------------------- > > Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards > it gives me: > > exp(2.000000) is > 7.38905609893065040 > expl(2.000000) is > 7.38905609893065022739 > > Already the sixteenth position after decimal point differs. DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18. You can expect at most 15 correct digits from exp(). > Please forgive me, if this is a really stupid approach for producing > some expl() output. If you actually want to test expl() to see if it is producing a decent result, you need a reference solution that contains a higher precision. I use mpfr with 256 bits of precision. troutmask:fvwm:kargl[213] ./testl -V 2 ULP = 0.3863 x = 2.000000000000000000e+00 libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2 mpfr: 7.3890560989306502272304274605750078131803155705518\ 47324087127822522573796079054e+00 mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0 The 1st 'mpfr:' line is produced after converting the results fof mpfr_exp() to long double. The 2nd 'mpfr:' line is produced by mpfr_printf() where the number of printed digits depends on the 256-bit precision. The last 'mpfr:' line is mpfr_printf()'s hex formatting. Unfortunately, it does not normalize the hex representation to start with '0x1.', which makes comparison somewhat difficult. -- Steve