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: Wed, 20 Mar 2024 20:47:02 +0000
Organization: Rocksolid Light
Message-ID: <f70bb5a0593faf21ddf941798a5ff976@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> <936a852388e7e4414cb7e529da7095ea@www.novabbs.org> <ur9qtp$fnm9$1@dont-email.me> <20240314112655.000011f8@yahoo.com> <jwv1q87l5ou.fsf-monnier+comp.arch@gnu.org> <9a5b9a6a445bd41ff75a93b589982970@www.novabbs.org> <jwv8r2djafq.fsf-monnier+comp.arch@gnu.org> <20240320182147.000067e1@yahoo.com> <utf4s1$1jei0$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="2661356"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$uPPKU/dBxQiK1qP3WgflEObduvypS2yJPsxmKAEGRKnZ8EKC3okb2
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3238
Lines: 39

Steven G. Kargl wrote:

> On Wed, 20 Mar 2024 18:21:47 +0200, Michael S wrote:

>> On Wed, 20 Mar 2024 09:54:36 -0400
>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>>> >>>> There are groups who have shown that exactly rounded
>>> >>>> trancendental functions are in fact achievable with maybe 3X
>>> >>>> reduced performance.  
>>> >> That much?  I had the impression it was significantly cheaper.  
>>> > The J. M. Muller book indicates about 2× to 2.5×  
>>> 
>>> The [Rlibm](https://people.cs.rutgers.edu/~sn349/rlibm/) project
>>> claims to get much better performance (basically, in the same
>>> ballpark as not-correctly-rounded implementations).
>>> 
>> 
>> I had only read the 1st page.
>> It sounds like they are not particularly interested in IEEE binary64
>> which appears to be the major point of interest of math libs of
>> conventional languages.
>> 

> I skimmed their logf(x) implementation.  Their technique will
> fall a part for binary64 (and other higher precisions).  With
> logf(x), they combine an argument step with table look-up and
> a 5th-order polynomial approximation.  The polynomial is computed
> in double precision, and provides the correct rounding.  For
> binary64, the polynomial would require many more terms and 
> double-double or binary128 evaluation.  

The first 7 terms of the DP polynomial do not require FP128, whereas
the last 3 do/will.

Whereas: HW with 64-bits of fraction does not need FP128 at all.
64-bits of fraction with 64-bit coefficients added into a 128-bit 
accumulator is more than sufficient.

Note FP64 has 53-bits of fraction.....