Date: Thu, 7 Mar 2019 15:09:06 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-numerics@freebsd.org Subject: Re: Update ENTERI() macro Message-ID: <20190307144315.N932@besplex.bde.org> In-Reply-To: <20190306214233.GA23159@troutmask.apl.washington.edu> References: <20190227074811.GA75972@troutmask.apl.washington.edu> <20190227201214.V1823@besplex.bde.org> <20190227161906.GA77785@troutmask.apl.washington.edu> <20190228060920.R4413@besplex.bde.org> <20190304212159.GA12587@troutmask.apl.washington.edu> <20190305153243.Y1349@besplex.bde.org> <20190306055201.GA40298@troutmask.apl.washington.edu> <20190306225811.P2731@besplex.bde.org> <20190306184829.GA44023@troutmask.apl.washington.edu> <20190307061214.R4911@besplex.bde.org> <20190306214233.GA23159@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Mar 2019, Steve Kargl wrote: > On Thu, Mar 07, 2019 at 06:30:42AM +1100, Bruce Evans wrote: >> ... >> I now see that you implemented 2 more versions of __ldexpl_cexpl() by >> cloning the old double precision version. Apparently the includes >> are to unpolluted for the compiler to see the multiple versions :-). >> >> Using the version in k_expl.h almost forces inlining of expl()'s kernel >> and its large tables, just like for hyperbolic functions. This wastes >> a lot of space, especially for duplicating the tables. It is only a >> small optimization for time. It is done for the hyperbolic functions >> to get this optimization, and for __ldexpl_cexpl() just for convenience. > > The version in k_expl.h has 2 bugs. You note the first (cos instead > of cosl). The second is > > In file included from /data/kargl/trunk/math/libm/msun/ld80/s_cexpl.c:43: > /data/kargl/trunk/math/libm/msun/ld80/k_expl.h:288:22: error: magnitude of > floating-point constant too large for type 'double'; maximum is > 1.7976931348623157E+308 [-Werror,-Wliteral-range] > exp_x = (lo + hi) * 0x1p16382; > ^ It is missing an L suffix. Clearly not tested. >>> [errors for cexpl()] >> >> Check a few denormals, Infs and NaNs. > > Exceptional cases give > > % ./testl -e > cexpl(1, inf) = (nan,nan) expecting (nan,nan) > cexpl(1,-inf) = (nan,nan) expecting (nan,nan) > cexpl(nan,-inf) = (nan,nan) expecting (nan,nan) > cexpl(nan, inf) = (nan,nan) expecting (nan,nan) > cexpl(inf, inf) = (inf,nan) expecting (inf,nan) > cexpl(inf,-inf) = (inf,nan) expecting (inf,nan) > cexpl(inf,nan) = (inf,nan) expecting (inf,nan) > cexpl(-inf,nan) = (0,0) expecting (0,0) > cexpl(-inf,-inf) = (0,0) expecting (0,0) > cexpl(-inf, inf) = (0,0) expecting (0,0) But does it preserve NaN bits as much as possible, and produce the same NaN bits as double precision after conversion to double precision? The report spells NaN and Inf using C99's fuzzy bad names. Even the C99 specification spells NaN and Inf correctly in Appendix F. The complex hyperbolic functions have better comments, so are almost an easier place to start. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190307144315.N932>