From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13850 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:30:31 +0100 Message-ID: <20190223203030.GX21289@port70.net> References: 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="21946"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Shane Seelig To: musl@lists.openwall.com Original-X-From: musl-return-13866-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 23 21:30:46 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 1gxdwb-0005bi-NA for gllmg-musl@m.gmane.org; Sat, 23 Feb 2019 21:30:45 +0100 Original-Received: (qmail 10161 invoked by uid 550); 23 Feb 2019 20:30:43 -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 10143 invoked from network); 23 Feb 2019 20:30:42 -0000 Mail-Followup-To: musl@lists.openwall.com, Shane Seelig Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13850 Archived-At: * 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. 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.