From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13851 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: x87 asin and acos Date: Sat, 23 Feb 2019 21:36:23 +0100 Message-ID: <20190223203621.GY21289@port70.net> References: <20190223203030.GX21289@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="47726"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com, Shane Seelig Original-X-From: musl-return-13867-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 23 21:36:37 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gxe2H-000CJz-Jh for gllmg-musl@m.gmane.org; Sat, 23 Feb 2019 21:36:37 +0100 Original-Received: (qmail 15857 invoked by uid 550); 23 Feb 2019 20:36:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15839 invoked from network); 23 Feb 2019 20:36:34 -0000 Mail-Followup-To: musl@lists.openwall.com, Shane Seelig Content-Disposition: inline In-Reply-To: <20190223203030.GX21289@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:13851 Archived-At: * Szabolcs Nagy [2019-02-23 21:30:31 +0100]: > * Shane Seelig [2019-02-23 09:21:08 -0500]: > > Currently 'asin' uses the algorithm: > > arcsin(x) == arctan(x/(sqrt((1-x)(1+x)))) > > If the following algorithm were to be used instead, an 'fadd' could be > > removed. > > arcsin(x) == arctan(x/(sqrt(1-x**2))) > > that change seems valid as far as the result is concerned. > (the worst case rounding error of the sqrt argument should > be around LDBL_EPS in both cases) > > but the fenv behaviour is not valid: > for tiny x, x*x raises spurious underflow exception > for large x, x*x raises spurious overflow exception > > (1-x)(1+x) avoids these issues. hm actually this does not solve the overflow prolem, indeed current asinl(0x1p10000L) raises spurious overflow, so it's not correct. (it's unlikely to matter in practice, the valid input domain is [-1,1] anyway, but we should probably fix that) > > note that there is not much performance difference between > the two expressions: 1-x and 1+x are independent computations > so the latency is 1 add + 1 mul in both cases, and the entire > function is likely dominated by fpsqrt followed by fpatan > both of which have huge latency compared to add or mul.