Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Radians Or Degrees?
Date: Wed, 20 Mar 2024 12:59:24 -0400
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <jwvr0g4j1ta.fsf-monnier+comp.arch@gnu.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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="08c998265a5aa3c91d4e4d5bc7e921b3";
	logging-data="1691518"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GAujKTRQM7dUiPgeq/LHbDbLaJV+Rhwg="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:0VJh6KLw7G5wBhVCnjrcHRJsDFI=
	sha1:2yzPqhZauM5Q5xcdtkb2nrdc2pU=
Bytes: 3950

>> 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.

Indeed, I hoped by now they had attacked the world of 64bit floats, but
it looks like it's not the case yet.  In theory the same idea is
applicable there and should give similar results, but of course it's
harder for two reasons:

- The search space to consider is much larger, making it much more
  costly to do exhaustive testing (and to collect the info they need to
  choose/compute the polynomials).
- You can't cheaply use higher-precision floats for internal computations.

> It all depend of what you compare against.
> For scalar call for majority of transcendental functions on IEEE-754
> list, it's probably very easy to get correctly rounded binary32 results
> in approximately the same time as results calculated with max. err of,
> say, 0.75 ULP. Especially so if target machine has fast binary64
> arithmetic.

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.

> I don't want to pay for correct rounding of transcendental functions.
> Neither in speed and especially nor in tables footprint.  Not even a
> little.  Because for me there are no advantages.

For that reason, correctly rounded results were nowhere near the menu,
indeed.  But the proposition of Rlibm is that maybe we can have our cake
and eat it too, because (if all goes well) you don't have to pay for it
in speed nor in table size.

I'm hoping that pans out :-)

> Now, there are things that I am ready to pay for. E.g. preservation of
> mathematical properties of original exact function. I.e. if original is
> monotonic on certain interval then I do want at least weak monotonicity
> of approximation. If original is even (or odd) I want the same for
> approximation. If original never exceed 1, I want the same
> for approximation. Etc... But correct rounding is not on the list.

But correct rounding would give you those properties.


        Stefan