From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Trigonometric operations on x86 and x64 CPUs Date: Tue, 20 Dec 2016 19:20:50 -0600 Organization: JSA Research & Innovation Message-ID: References: <8d0f7f03-9324-4702-9100-d6b8a1f16fc5@googlegroups.com> <18af86db-21fd-4fa0-90a3-c87b6486b439@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1482283250 7885 24.196.82.226 (21 Dec 2016 01:20:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 21 Dec 2016 01:20:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Xref: news.eternal-september.org comp.lang.ada:32932 Date: 2016-12-20T19:20:50-06:00 List-Id: wrote in message news:c3725fa2-7eaa-4020-b0ae-6ddcfc2a3d1d@googlegroups.com... ... >At first glance it seems that Randy Brukardt is correct. It seems likely, even though today I'd be hard pressed to explain why in any detail. We're talking about work done in the mid-1990s. >Assuming IEEE binary64, for any x in range [-2**26.5..2**26.5] requirements >want Sin(x) to return the number in range [exact_sin(x)*(1-d*2**53) .. >exact_sin(x)*(1+d*2**(-53))] where d=2. >x87 SIN instruction by itself achieves specified precision in smaller range > (~ up to abs(x) < 2^14). > >It means that conforming implementations of Ada libraries forced to spends >a significant effort doing reduction of stupidly big arguments of >sin/cos/tan. Also on doing sanity checks of operands (but of course that's generally a strength of Ada). A version of GEF (Generic_Elementary_Functions) that used Ada 2012 preconditions could avoid much of that overhead, and would be an advantage for really speed-critical operations. >On the other hand The Requirements allow rather poor precision for small >arguments (d=2) where better precision (d=1.25 or d=1.125) is both >desirable and not especially hard to achieve. Keep in mind that the requirements were written by a team of numerical analysis experts in 1992-4 based on the state of the art at that time. (Probably the Cody/Waite algorithms.) Those of us who maintain the Standard today don't really have the expertise to make any informed changes to these rules, so for the most part we keep our hands off (the worst thing we could do would be to mess up carefully considered rules - but we have fixed a number of obvious errors). >There is a consolation, too - the range reduction in the minimal range >required >by the standard can be done without big tables. And it can be implemented >relatively quickly if the hardware features fused multiply-add. My recollection is that it isn't even that bad if one writes the entire algorithm in Ada. (Since our compiler generally keeps intermediate results in the 80-bit extended format, we tended to write as much as possible as a single large expression. Probably could do that even better today with Ada 2012 conditional expressions.) >On somewhat related note, it seems to me that forward trigonometric >functions >with 'Cycle' argument are underspecified. I'd like the requirements for >extremely >useful special cases of 'Cycle' == exact power of 2 to be more pronounced. It's certainly possible. We'd welcome someone with substantial numeric experience contributing to the ARG for Ada Standards maintenance. Most of us know enough to understand the Ada numeric model and when something is incorrect for it, but we don't have anyone very good at the subtle details. Randy.