Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Radians Or Degrees?
Date: Sat, 23 Mar 2024 09:11:38 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <utm2rr$3hb2q$1@dont-email.me>
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>
 <jwvr0g4j1ta.fsf-monnier+comp.arch@gnu.org>
 <7df63e6620be0871ed9201ae9bedf765@www.novabbs.org>
 <utgovj$2360k$1@dont-email.me> <20240321145133.0000160f@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 23 Mar 2024 08:11:39 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="00aa802448ec57a94e59f55df19f8322";
	logging-data="3714138"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+YCQk10Wz//8W24VPzFTDsz3/0CZyGrWhhDZjloyZ39Q=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.1
Cancel-Lock: sha1:nLpTckvMla8WUS88majnay+ov9A=
In-Reply-To: <20240321145133.0000160f@yahoo.com>
Bytes: 4586

Michael S wrote:
> On Thu, 21 Mar 2024 08:52:18 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>=20
>> MitchAlsup1 wrote:
>>> Stefan Monnier wrote:
>>>> IIUC that was not the case before their work: it was "easy" to get
>>>> the correct result in 99% of the cases, but covering all 100% of
>>>> the cases used to be costly because those few cases needed a lot
>>>> more internal precision.
>>>
>>> Muller indicates one typically need 2=C3=83=E2=80=94n+6 to 2=C3=83=E2=
=80=94n+12 bits to get
>>> correct roundings 100% of the time. FP128 only has 2=C3=83=E2=80=94n+=
3 and is
>>> insufficient by itself.
>>
>> I agree with everything else you've written about this subject, but
>> afair, fp128 is using 1:15:112 while double is of course 1:10:53.
>>
>=20
> IEEE-754 binary64 is 1:11:52 :-)

Oops! Mea Culpa!
I _do_ know that double has a 10-bit exponent bias (1023), so it has to=20
be 11 bits wide. :-(

>=20
> But anyway I am skeptical about Miller's rules of thumb.
> I'd expect that different transcendental functions would exercise
> non-trivially different behaviors, mostly because they have different
> relationships between input and output ranges. Some of them compress
> wider inputs into narrower output and some do the opposite.
> Yet another factor is luck.

I agree, this is a per-function problem, with some being substantially=20
harder than others.
>=20
> Besides, I see nothing special about binary128 as a helper format.
> It is not supported on wast majority of HW, And even when it is
> supported, like on IBM POWER, for majority of operations it is slower
> than emulated 128-bit fixed-point. Fix-point is more work for coder, bu=
t
> sounds like more sure path to success.

In my own code (since I don't have Mitch's ability to use much wider=20
internal fp formats) I also prefer 64-bit u64 as the working chunk size.

Almost 30 years ago, during the FDIV workaround, I needed a q&d way to=20
verify that our fpatan2 replacement was correct, so what I did was to=20
write a 1:31:96 format library over a weekend.

Yeah, it was much more exponent than needed, but with only 32-bit=20
registers available it was much easier to get the asm correct.

For the fpatan2 I used a dead simple approach with little range=20
reduction, just a longish Taylor series (i.e. no Cheby optimizations).

I had previously written 3-4 different iomplementations of arbitrary=20
precision atan2() when I wanted to calculatie as many digits of pi as=20
possible, so I just reused one of those algorithms.

Terje


--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"