From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 30 22:39:36 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A318A51; Fri, 30 Jan 2015 22:39:36 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8372100; Fri, 30 Jan 2015 22:39:35 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t0UMdHAK079701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 31 Jan 2015 09:39:23 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t0UMdAOC010935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 31 Jan 2015 09:39:10 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t0UMd9Ed010934; Sat, 31 Jan 2015 09:39:09 +1100 (AEDT) (envelope-from peter) Date: Sat, 31 Jan 2015 09:39:09 +1100 From: Peter Jeremy To: Steve Kargl Subject: Re: clang is almost useless for complex arithmetic Message-ID: <20150130223909.GA10817@server.rulingia.com> References: <20140326002205.GA9940@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20140326002205.GA9940@troutmask.apl.washington.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-numerics@freebsd.org, freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 22:39:36 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable To resurrect an old thread... On 2014-Mar-25 17:22:05 -0700, Steve Kargl wrote: >It appears that clang developers have chosen the naive >complex division algorithm, and it does not matter whether >one turns CX_LIMITED_RANGE on or off. This means that=20 >if one uses clang with complex types, one must be careful >with the range of values allowed in complex division. In >other words, implementation of complex libm routines cannot >use complex data types and must fallback to a decomposition >into real and imaginary components.=20 Whilst the fixes don't seem to have made it into FreeBSD yet, it seems that this has been improved in recent Clang/LLVM - see http://reviews.llvm.org/D5698, committed as rL219557. I re-implemented their division algorithm in C and checked it against the algorithms listed in http://arxiv.org/pdf/1210.4539v2.pdf. Whilst it fails on same of the difficult values listed in that paper, when faced with a range of random arguments, it seems to perform better[*] than the "robust" algorithm. I didn't look closely at the multiplication algorithm but, based on a quick look, it seems that it's still susceptable to spurious overflows. [*] or at least closer to the result given by the naive algorithm using x87 long doubles. --=20 Peter Jeremy --zhXaljGHf11kAtnf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUzAgNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0NHwP/RRvnj9dVpunArX8WNe/eTty JWtsL0OiQCmRxvUa+1nmAggUJxxXxjEhwx2CwrBRZEBppKOdxrCrcUxd6lwa56Xz d/phocOUckfbDT4JaiksQHhucba0fXW06MuAiqnc6pYEOvWj715Lz3VkICJG/ZMZ sIq6R0g+/4ZFXMHybVBH65hiiIXzFiWIIyx2XyOb14zrgCxPHPGpQDPiddiuQTPD cB1WLcNUpKDwAR0f8WFsvZLLxJ8Zj23IyjMNzI2Tlb1IhoCTRUmMYdXZyg3ai1XY fqpts+pR2JMTDddR4Sp1W1uwPKYASFx7wxZOkWyd52YMx7zvvNHuPhc3HAvVxJxw +cePrV6ArlWU+/pEXO5KlsYtB2XLbqLLSzsKEVOWC8eOUWmjs0aTPXqHQ3SLzoGz J5y4K6rNc1z+kuHBOoJItYXAL8GYLUDC13ZnDX7DYTfTZHE5JN2sKs5FZPO8GujS hGzCm3D6xvk6+zbQcrTzS5C+wQtYc5kKfM2EqcHfcY0R0kMWFYO5qe4mia2oP+xk 4uSahOYPmnuLM3wrOrOO+y+GBLIdkJPEZc8w3UZtxhULC3h3ohHLKdfQQGBvyeG9 00o0jNH4hJ0SFT9u6gX2EfHv0nEwlwZzzaPsvTpQy9TyoVsGY4ipduheBqzaZ+kW 1IaujlvmTTAfcqP8Aoms =VeVJ -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--