Date: Wed, 3 Jun 2015 20:23:24 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: "Montgomery-Smith, Stephen" <stephen@missouri.edu>, "freebsd-numerics@freebsd.org" <freebsd-numerics@freebsd.org> Subject: Re: Let's get moving Message-ID: <20150603201258.I1997@besplex.bde.org> In-Reply-To: <20150602002619.GA45253@troutmask.apl.washington.edu> References: <556CEB8C.90605@missouri.edu> <20150602002619.GA45253@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jun 2015, Steve Kargl wrote: >> From src/math_private.h > > * 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. > > Last time I checked, clang was even worse with regards to I. C11 now has CPLX() that can be used to handle this, and is used in a way that I don't like (to replace our old method). clang has some library support to do complex operations better. There are well known overflow problems for division, and even for addition if you want to let the real and imaginary parts overflow independently like we do in catrig*.c. The library functions might handle Infs and NaNs too. I haven't checked what they actually do. If you actually use them for every operation, then every operation becomes slow. libm wouldn't notice much since it mostly reduces to real and imaginary parts internally. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150603201258.I1997>