Path: ...!news.misty.com!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Radians Or =?UTF-8?B?RGVncmVlcz8=?=
Date: Thu, 14 Mar 2024 17:15:11 +0000
Organization: Rocksolid Light
Message-ID: <9fcb5c6dc0bc30fadff42be770fdb896@www.novabbs.org>
References: <ur5trn$3d64t$1@dont-email.me> <ur5v05$3ccut$1@dont-email.me> <20240222015920.00000260@yahoo.com> <ur69j9$3ftgj$3@dont-email.me> <ur86eg$1aip$1@dont-email.me> <ur88e4$1rr1$5@dont-email.me> <ur8a2p$2446$1@dont-email.me> <ur8ctk$2vbd$2@dont-email.me> <20240222233838.0000572f@yahoo.com> <3b2e86cdb0ee8785b4405ab10871c5ca@www.novabbs.org> <ur8nud$4n1r$1@dont-email.me> <20240223143250.000012a8@yahoo.com> <59454a79216ece74ac3fee0e00473357@www.novabbs.org> <uravp3$nl44$1@dont-email.me> <9862882e1badcd541491098b47c61802@www.novabbs.org> <urb6qn$phho$2@dont-email.me> <urbpps$10mal$1@dont-email.me> <urbvdd$11l69$1@dont-email.me> <urc1f6$11u41$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1979508"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$5Sy4zvy/ouhFqz3M0Cz7RO86T/jRVOurmGdqe7RWCh/jvHEc/jmGO
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3303
Lines: 35

Steven G. Kargl wrote:


> sin(x) is not sinpi(x).  The conversion factor that you're missing
> is M_PI as in sinpi(x) = sin(M_PI*x).  

When I faced this kind of accuracy/precision problem in my HW transcendentals,

To get a sufficiently correct reduced argument I had to multiply the fraction
of x by a 2/pi number selected such that the HoB was aligned to 2 (quadrant)
and the multiplied result had 51+53 bits of precision so that up to 51 leading
bits of the reduced argument (after the quadrant bits) could be skipped if 0.
This required 3 uses of the multiplier tree one produced the leading bits::

Lead    bits |/
Middle  bits / /
trail   bits /|

which were arranged |/ /| into a single 104 bit (minimum) product. My current
implementation uses 128 bits. And my polynomial evaluation uses 58-bit argu-
ments (min, 64-bit current) at each iteration. And I still only get 0.502
(58-bit:: 0.5002 64-bit) precision.

Payne and Hanek argument reduction--because it does not have access to the 
intermediate bits, needs 4 multiplies instead of 2 and very careful arithmetic
to preserve accuracy. I can do this in 2 trips through the multiplier array
(patented)

So, I used 159-bits of 2/pi in 2 multiplies over 2 trips through the array
and get perfect argument (DP) reduction in 4 cycles. Payne ad Hanek use 256-
bits of DP FP operands and 30+ instruction to do the same thing.

My multiplier tree is cut into 2 sections (just like one would do for dual SP)
but here I feed the top 2/pi bits into the left hand side and the bottom 2/pi 
bits into the right hand side so both get computed simultaneously; the subsequent
cycle multiplies by the middle bits of 2/pi. The 2/pi table is indexed by exponent.