Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #382888 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-02-21 22:35 +0000 |
| Last post | 2024-02-22 19:44 +0000 |
| Articles | 20 on this page of 166 — 20 participants |
Back to article view | Back to comp.lang.c
Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-21 22:35 +0000
Re: Radians Or Degrees? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-21 17:55 -0500
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-02-22 01:59 +0200
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 01:55 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-22 19:14 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 19:48 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-22 20:16 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 21:04 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-02-22 23:39 +0200
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 21:47 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-22 22:57 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-23 00:13 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-22 16:49 -0800
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-22 16:59 -0800
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-23 02:42 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-23 12:28 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 22:42 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-24 12:40 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 22:52 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-24 19:26 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 06:30 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-22 21:58 -0700
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-23 02:28 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-02-23 11:10 +0100
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-14 11:26 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-14 17:34 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-14 19:48 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-15 12:16 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-14 20:30 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-14 15:12 -0700
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-14 22:19 +0000
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-14 15:21 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-14 15:22 -0700
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-15 13:49 +0200
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-15 11:23 +0100
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-15 14:15 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-16 01:23 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-16 16:59 +0100
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-15 13:59 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-15 14:13 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-16 13:23 -0700
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-15 14:16 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-15 14:26 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-15 14:30 -0700
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-15 15:48 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-17 13:41 -0700
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-17 21:49 -0700
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-16 01:16 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-16 19:08 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-16 17:22 +0000
Re: Radians Or Degrees? scott@slp53.sl.home (Scott Lurndal) - 2024-03-16 18:32 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-16 20:49 +0200
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-16 16:19 -0700
Re: Radians Or Degrees? bart <bc@freeuk.com> - 2024-03-17 00:00 +0000
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-16 18:38 -0700
Re: Radians Or Degrees? bart <bc@freeuk.com> - 2024-03-17 01:57 +0000
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-16 19:57 -0700
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-03-17 13:10 +0100
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-17 11:06 +0200
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-17 11:34 +0200
Re: Radians Or Degrees? bart <bc@freeuk.com> - 2024-03-17 10:59 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-17 14:15 +0200
Re: Radians Or Degrees? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-15 15:13 -0700
Re: Radians Or Degrees? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-18 15:18 -0400
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-18 22:19 +0000
Re: Radians Or Degrees? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-20 09:54 -0400
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-20 18:21 +0200
Re: Radians Or Degrees? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-20 12:59 -0400
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-20 20:40 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-21 08:52 +0100
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-21 14:51 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-21 16:37 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-23 09:11 +0100
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-03-20 17:02 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-20 20:47 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-20 20:33 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-03-21 00:03 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-20 20:26 +0000
Re: Radians Or Degrees? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-20 16:34 -0400
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-03-21 08:38 +0100
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-02-23 14:32 +0200
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-23 20:02 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-23 20:38 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-23 22:29 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 22:39 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-24 04:03 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 04:47 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-24 05:27 +0000
Re: Radians Or Degrees? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-24 05:48 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 05:38 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-24 06:13 +0000
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-03-14 17:15 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-23 23:20 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 22:39 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-23 23:16 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 23:44 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-24 01:15 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 01:19 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-24 01:27 +0000
Re: Radians Or Degrees? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-24 01:42 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-25 00:18 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-02-25 12:57 +0200
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 02:21 +0000
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-24 02:49 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 03:07 +0000
Re: Radians Or Degrees? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-24 03:12 +0000
Re: Radians Or Degrees? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-23 18:49 -0800
Re: Radians Or Degrees? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-23 23:30 +0000
Re: Radians Or Degrees? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-24 02:25 -0500
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 21:21 +0000
Re: Radians Or Degrees? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-24 17:32 -0500
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 22:50 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-02-25 16:19 +0100
Re: Radians Or Degrees? mitchalsup@aol.com (MitchAlsup1) - 2024-02-25 18:11 +0000
Re: Radians Or Degrees? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-02-23 11:01 +0100
Re: Radians Or Degrees? "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2024-02-22 22:09 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 22:30 +0000
Re: Radians Or Degrees? Michael S <already5chosen@yahoo.com> - 2024-02-23 00:56 +0200
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 23:03 +0000
Re: Radians Or Degrees? fir <fir@grunge.pl> - 2024-02-22 00:15 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 01:55 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 09:32 +0100
Re: Radians Or Degrees? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-22 09:38 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 11:04 +0100
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-22 14:28 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 16:26 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 19:45 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-22 21:30 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-23 09:11 +0100
GGs [was Radians Or Degrees?] Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-23 13:57 +0000
Re: GGs [was Radians Or Degrees?] "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-23 11:15 -0800
Re: GGs [was Radians Or Degrees?] Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-23 19:26 +0000
Re: Radians Or Degrees? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-22 07:17 +0000
Re: Radians Or Degrees? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-22 16:49 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 09:06 +0100
Re: Radians Or Degrees? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-22 08:27 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 11:09 +0100
Re: Radians Or Degrees? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-22 13:48 +0000
Re: Radians Or Degrees? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-22 15:29 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-22 20:02 +0100
Re: Radians Or Degrees? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-23 02:15 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 02:24 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-23 09:16 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 19:39 +0000
Re: Radians Or Degrees? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-22 21:25 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 20:58 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-23 09:33 +0100
Re: Radians Or Degrees? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-23 12:53 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-23 20:23 +0000
Re: Radians Or Degrees? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-25 11:19 +0000
Re: Radians Or Degrees? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-25 13:08 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 22:21 +0000
Re: Radians Or Degrees? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-25 22:29 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 21:29 +0000
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-26 13:44 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 23:15 +0000
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-26 16:02 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 00:55 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-27 09:53 +0100
Re: Radians Or Degrees? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-25 14:43 -0800
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 21:32 +0000
Re: Radians Or Degrees? bart <bc@freeuk.com> - 2024-02-25 23:09 +0000
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 21:32 +0000
Re: Radians Or Degrees? bart <bc@freeuk.com> - 2024-02-26 23:01 +0000
Re: Radians Or Degrees? David Brown <david.brown@hesbynett.no> - 2024-02-27 09:59 +0100
Re: Radians Or Degrees? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-22 19:44 +0000
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-03-17 10:59 +0000 |
| Message-ID | <ut6if0$3fvei$1@dont-email.me> |
| In reply to | #383673 |
On 17/03/2024 09:06, Michael S wrote:
> On Sat, 16 Mar 2024 16:19:11 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> As written, your example does not emphasize that the problem has
> nothing to do with implementation of sinX() library routine.
> It's best illustrated by followup conversation with bart, IMHO 100%
> O.T.
Actually, the thread topic is the more basic one of whether angles to
these functions should be specified as degrees or radians.
In answer to that, I decided long ago (in my language designs) to keep
them as radians, but allow degrees for constants if written in one of
these styles like this:
sin(30°) + cos(60 deg)
Because, once they're inside a variable:
sin(alpha) + cos(beta)
then the unit used is irrelevant.
As for the value returned from sin() etc, I haven't worried about that
since last century.
Except briefly more recently when I had an arbitrary precision floating
point library and considered whether to add such functions, but
concluded I didn't have the right skills, experience (of using
ultra-high precision trig functions) or motivation.
The first problem was: exactly how accurately should it be generated.
With ieee754 it's easy, you only have 53 binary digits to fill.
In my (decimal) library, the default precision for a calculation like
1.0/3.0 is typically set up to 500 decimal digits, or about 1600 bits,
otherwise it will keep going forever (the theoretical limit is 19
billion decimal digits, or 64 billion bits).
The second problem was, how do you even calculate sin(x) so that it
converges to that accuracy within a reasonable amount of time? The
Taylor series that I used to use wouldn't cut it.
(Dealing with inputs that are extreme multiples of +/- 2pi radians would
be an additional difficulty.)
I decided not to bother with transcendental functions.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-17 14:15 +0200 |
| Message-ID | <20240317141527.00002a11@yahoo.com> |
| In reply to | #383678 |
On Sun, 17 Mar 2024 10:59:46 +0000 bart <bc@freeuk.com> wrote: > On 17/03/2024 09:06, Michael S wrote: > > On Sat, 16 Mar 2024 16:19:11 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > > As written, your example does not emphasize that the problem has > > nothing to do with implementation of sinX() library routine. > > It's best illustrated by followup conversation with bart, IMHO 100% > > O.T. > > > Actually, the thread topic is the more basic one of whether angles to > these functions should be specified as degrees or radians. > Degrees can be seen as a form of turn==circle-based units, but for most purposes except interaction with user they are not quite as convenient as plain turns or than turns multiplied by some negative power of two. > In answer to that, I decided long ago (in my language designs) to > keep them as radians, but allow degrees for constants if written in > one of these styles like this: > > sin(30°) + cos(60 deg) > > Because, once they're inside a variable: > > sin(alpha) + cos(beta) > > then the unit used is irrelevant. > > As for the value returned from sin() etc, I haven't worried about > that since last century. > > Except briefly more recently when I had an arbitrary precision > floating point library and considered whether to add such functions, > but concluded I didn't have the right skills, experience (of using > ultra-high precision trig functions) or motivation. > > The first problem was: exactly how accurately should it be generated. > With ieee754 it's easy, you only have 53 binary digits to fill. > > In my (decimal) library, the default precision for a calculation like > 1.0/3.0 is typically set up to 500 decimal digits, or about 1600 > bits, otherwise it will keep going forever (the theoretical limit is > 19 billion decimal digits, or 64 billion bits). > > The second problem was, how do you even calculate sin(x) so that it > converges to that accuracy within a reasonable amount of time? The > Taylor series that I used to use wouldn't cut it. There exist better series than Taylor, but in case of high-precision sin()/cos() they are not MUCH better. Typically, just one term shorter than Taylor for a given precision, at most two terms. And quite often this additional terms can be done with lower precision (e.g. IEEE binary) so in terms of execution time the difference is close to noise. The key to faster high-prec sin()/cos() is breaking quarter-circle of input into more ranges. For 1600 bits you would almost certainly want to do it hierarchically. I never dealt with such high precision myself so has no intuition about number of levels. For (much) lower precision I used 6 or 7 bits per level of hierarchy, but with 1600 bits I'd think that it makes sense to use fewer bit per level in order to keep total size of the tables within limits of 2nd-level cache of typical CPU. May be, 7 bits on few higher levels and then 1 or 2 bits for the rest? Now, too many levels of hierarchy cause the problems of their own, specifically, intermediate calculations would likely need higher precision. The trade offs are not simple :( > > (Dealing with inputs that are extreme multiples of +/- 2pi radians > would be an additional difficulty.) > > I decided not to bother with transcendental functions. > You can solve most of your problems by integrating MPFR into your runtime.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-03-15 15:13 -0700 |
| Message-ID | <ut2h6p$2g9l4$1@dont-email.me> |
| In reply to | #383638 |
On 3/15/2024 1:59 PM, Chris M. Thomasson wrote: > On 3/15/2024 3:23 AM, Terje Mathisen wrote: >> Michael, I for the main part agree with you here, i.e. calculating >> sin(x) with x larger than 2^53 or so, is almost certainly stupid. > [...] > > ;^D tooooooo big. :^) Actually, I can think of one of my fractals that tries to scale back numbers that get too big. https://www.shadertoy.com/view/XtscDl When a complex number breaches an escape time barrier, my code simply scales it back, say z = z * .242, and tries the fractal again. It has the effect of exploding the fractal out beyond its original boundaries... > > Now, wrt the results, arbitrary precision for trig is useful, in say... > Deep fractal zooms... > > Zooming in really deep in say something like this, well the precision of > trig can become an issue: > > https://paulbourke.net/fractals/multijulia/ > > Trig would be used, say, in rectangular to-from polar forms wrt getting > the n-ary roots of a complex number? >
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-03-18 15:18 -0400 |
| Message-ID | <jwv1q87l5ou.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #383605 |
>> 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.
> At which cost in tables sizes?
My impression was that it wasn't costly in that respect, but since my
recollection seems to be off on the performance, maybe it's off here
as well.
> The critical point here is definition of what considered exact. If
> 'exact' is measured only on y side of y=foo(x), disregarding
> possible imprecision on the x side then you are very likely to end up
> with results that are slower to calculate, but not at all more useful
> from point of view of engineer or physicist. Exactly like Payne-Hanek
> or Mitch's equivalent of Payne-Hanek.
I don't know what are/were the motivations for the people working on
exact transcendentals, but they have applications unrelated to the fact
that they're "better": the main benefit (from this here PL guy) is that
it gives them a reliable, reproducible semantics.
Bit-for-bit reproducibility makes several things much easier.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-18 22:19 +0000 |
| Message-ID | <9a5b9a6a445bd41ff75a93b589982970@www.novabbs.org> |
| In reply to | #383726 |
Stefan Monnier 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× >> At which cost in tables sizes? Making transcendental faster is always a tradeoff between table size and speed. SIN() COS() can use 10-term polynomials when the reduced argument is -¼pi..+¼pi, on the other hand, when the reduced argument is ±0.008 a 3 term polynomial is just as accurate but you need 128×3 tables. > My impression was that it wasn't costly in that respect, but since my > recollection seems to be off on the performance, maybe it's off here > as well. ITANIC did rather well, here, because it had 2 FMAC units and could use both for the polynomials. >> The critical point here is definition of what considered exact. If >> 'exact' is measured only on y side of y=foo(x), disregarding >> possible imprecision on the x side then you are very likely to end up >> with results that are slower to calculate, but not at all more useful >> from point of view of engineer or physicist. Exactly like Payne-Hanek >> or Mitch's equivalent of Payne-Hanek. > I don't know what are/were the motivations for the people working on > exact transcendentals, but they have applications unrelated to the fact > that they're "better": the main benefit (from this here PL guy) is that > it gives them a reliable, reproducible semantics. > Bit-for-bit reproducibility makes several things much easier. Consider moving an application which uses libm from machine to machine. When libm is correctly rounded, there is no issue at all; not so other- wise. > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-03-20 09:54 -0400 |
| Message-ID | <jwv8r2djafq.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #383729 |
>>>> 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).
[ Their key insight is the idea that to get correct rounding, you
shouldn't try to compute the best approximation of the exact result
and then round, but you should instead try to compute any
approximation whose rounding gives the correct result. ]
My impression was that their performance was good enough that the case
for not-correctly-rounded implementations becomes very weak.
>> I don't know what are/were the motivations for the people working on
>> exact transcendentals, but they have applications unrelated to the fact
>> that they're "better": the main benefit (from this here PL guy) is that
>> it gives them a reliable, reproducible semantics.
>> Bit-for-bit reproducibility makes several things much easier.
>
> Consider moving an application which uses libm from machine to machine.
> When libm is correctly rounded, there is no issue at all; not so other-
> wise.
Exactly!
[ Or should I say "Correctly rounded!"? ]
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-20 18:21 +0200 |
| Message-ID | <20240320182147.000067e1@yahoo.com> |
| In reply to | #383782 |
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. > [ Their key insight is the idea that to get correct rounding, you > shouldn't try to compute the best approximation of the exact result > and then round, but you should instead try to compute any > approximation whose rounding gives the correct result. ] > > My impression was that their performance was good enough that the case > for not-correctly-rounded implementations becomes very weak. > 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. But in practice when we use lower (than binary64) precision we often care about vector performance rather than scalar. I.e. we care little about speed of sinf(), but want ippsTone_32f() as fast as possible. In case you wonder, this function is part Intel Performance Primitives and it is FAST. Writing correctly rounded function that approaches the speed of this *almost* correctly rounded routine (I think, for sane input ranges it's better than 0.55 ULP) would not be easy at all! > >> I don't know what are/were the motivations for the people working > >> on exact transcendentals, but they have applications unrelated to > >> the fact that they're "better": the main benefit (from this here > >> PL guy) is that it gives them a reliable, reproducible semantics. > >> Bit-for-bit reproducibility makes several things much easier. > > > > Consider moving an application which uses libm from machine to > > machine. When libm is correctly rounded, there is no issue at all; > > not so other- wise. > > Exactly! > [ Or should I say "Correctly rounded!"? ] > > > Stefan You like this proposal because you are implementer of the language/lib. It makes your regression tests easier. And it's good challenge. I don't like it because I am primarily user of the language/lib. My floating-point tests have zero chance of repeatability of this sort for a thousand of other reasons. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-03-20 12:59 -0400 |
| Message-ID | <jwvr0g4j1ta.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #383795 |
>> 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
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-20 20:40 +0000 |
| Message-ID | <7df63e6620be0871ed9201ae9bedf765@www.novabbs.org> |
| In reply to | #383801 |
Stefan Monnier wrote: >>> 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. You can in HW, just not in SW. That is a strong algorithms to migrate these functions from SW procedures to HW instructions. You do not need FP128, just FP with a 64-bit fraction. >> It all depend of what you compare against. OK:: SIN(x) takes 19-cycles and is 0.5002 accurate with Payne & Hanek argument reduction--Against any SW implementation. >> 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. Yes, at the cost of 4× larger tables. > Especially so if target machine has fast binary64 >> arithmetic. Obviously. > 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×n+6 to 2×n+12 bits to get correct roundings 100% of the time. FP128 only has 2×n+3 and is insufficient by itself. >> 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
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-03-21 08:52 +0100 |
| Message-ID | <utgovj$2360k$1@dont-email.me> |
| In reply to | #383817 |
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×n+6 to 2×n+12 bits to get correct > roundings 100% of the time. FP128 only has 2×n+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. On the one hand, 53*2+6 -> 112, on the other hand (if we include the hidden bits) we get 54*2+5 -> 113. So significantly more than 2n+3 but not enough on its own to guarantee correct rounding. As Michael S have mentioned, we want these algorithms to work for vector/SIMD calculations, and at that point both lookup tables and widening the size of the temporaries are very costly. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-21 14:51 +0200 |
| Message-ID | <20240321145133.0000160f@yahoo.com> |
| In reply to | #383827 |
On Thu, 21 Mar 2024 08:52:18 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > 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×n+6 to 2×n+12 bits to get > > correct roundings 100% of the time. FP128 only has 2×n+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. > IEEE-754 binary64 is 1:11:52 :-) 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. 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, but sounds like more sure path to success. > On the one hand, 53*2+6 -> 112, on the other hand (if we include the > hidden bits) we get 54*2+5 -> 113. > > So significantly more than 2n+3 but not enough on its own to > guarantee correct rounding. > > As Michael S have mentioned, we want these algorithms to work for > vector/SIMD calculations, and at that point both lookup tables and > widening the size of the temporaries are very costly. > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-21 16:37 +0000 |
| Message-ID | <d8269e715ac6557d4265337f425d29a1@www.novabbs.org> |
| In reply to | #383831 |
Michael S wrote:
> On Thu, 21 Mar 2024 08:52:18 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>> 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×n+6 to 2×n+12 bits to get
>> > correct roundings 100% of the time. FP128 only has 2×n+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.
>>
> IEEE-754 binary64 is 1:11:52 :-)
> But anyway I am skeptical about Miller's rules of thumb.
See Chapter 10 "Elementary Functions: Algorithms and Implementation"
Jean-Michael Muller {you can find a free copy on the net} and in
particular tables 10.5-10.14 -- quoting from the book::
"In his PhD dissertation [206], Lef`evre gives algorithms for finding
the worst cases of the table maker’s dilemma. These algorithms use linear
approximations and massive parallelism. A recent presentation of these
algorithms, with some improvements, can be found in [207]. We have run
Lef`evre’s algorithms to find worst cases in double-precision for the
most common functions and domains. The results obtained so far, first
published in [208] are given in Tables 10.5 to 10.14
They are NOT rules of thumb !! But go read it for yourself.
> 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.
> 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, but
> sounds like more sure path to success.
>> On the one hand, 53*2+6 -> 112, on the other hand (if we include the
>> hidden bits) we get 54*2+5 -> 113.
>>
>> So significantly more than 2n+3 but not enough on its own to
>> guarantee correct rounding.
>>
>> As Michael S have mentioned, we want these algorithms to work for
>> vector/SIMD calculations, and at that point both lookup tables and
>> widening the size of the temporaries are very costly.
>>
>> Terje
>>
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-03-23 09:11 +0100 |
| Message-ID | <utm2rr$3hb2q$1@dont-email.me> |
| In reply to | #383831 |
Michael S wrote: > On Thu, 21 Mar 2024 08:52:18 +0100 > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > >> 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×n+6 to 2×n+12 bits to get >>> correct roundings 100% of the time. FP128 only has 2×n+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. >> > > 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 be 11 bits wide. :-( > > 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 harder than others. > > 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, but > sounds like more sure path to success. In my own code (since I don't have Mitch's ability to use much wider 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 verify that our fpatan2 replacement was correct, so what I did was to write a 1:31:96 format library over a weekend. Yeah, it was much more exponent than needed, but with only 32-bit registers available it was much easier to get the asm correct. For the fpatan2 I used a dead simple approach with little range reduction, just a longish Taylor series (i.e. no Cheby optimizations). I had previously written 3-4 different iomplementations of arbitrary precision atan2() when I wanted to calculatie as many digits of pi as possible, so I just reused one of those algorithms. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-03-20 17:02 +0000 |
| Message-ID | <utf4s1$1jei0$1@dont-email.me> |
| In reply to | #383795 |
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. -- steve
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-20 20:47 +0000 |
| Message-ID | <f70bb5a0593faf21ddf941798a5ff976@www.novabbs.org> |
| In reply to | #383802 |
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.....
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-20 20:33 +0000 |
| Message-ID | <874a1d36b91024222a126fbedb677615@www.novabbs.org> |
| In reply to | #383795 |
Michael S wrote: > On Wed, 20 Mar 2024 09:54:36 -0400 > Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> [ Their key insight is the idea that to get correct rounding, you >> shouldn't try to compute the best approximation of the exact result >> and then round, but you should instead try to compute any >> approximation whose rounding gives the correct result. ] >> >> My impression was that their performance was good enough that the case >> for not-correctly-rounded implementations becomes very weak. >> > 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. > But in practice when we use lower (than binary64) precision we often > care about vector performance rather than scalar. > I.e. we care little about speed of sinf(), but want ippsTone_32f() as > fast as possible. In case you wonder, this function is part Intel > Performance Primitives and it is FAST. Writing correctly rounded > function that approaches the speed of this *almost* correctly > rounded routine (I think, for sane input ranges it's better than > 0.55 ULP) would not be easy at all! I challenge ANY software version of SIN() correctly rounded or not to compete with my <patented> HW implementations for speed (or even power). >> >> I don't know what are/were the motivations for the people working >> >> on exact transcendentals, but they have applications unrelated to >> >> the fact that they're "better": the main benefit (from this here >> >> PL guy) is that it gives them a reliable, reproducible semantics. >> >> Bit-for-bit reproducibility makes several things much easier. >> > >> > Consider moving an application which uses libm from machine to >> > machine. When libm is correctly rounded, there is no issue at all; >> > not so other- wise. >> >> Exactly! >> [ Or should I say "Correctly rounded!"? ] >> >> >> Stefan > You like this proposal because you are implementer of the language/lib. > It makes your regression tests easier. And it's good challenge. > I don't like it because I am primarily user of the language/lib. My > floating-point tests have zero chance of repeatability of this sort for > a thousand of other reasons. > I don't want to pay for correct rounding of transcendental functions. Even when the HW is 7× faster than SW algorithms ?? > Neither in speed and especially nor in tables footprint. Not even a > little. Because for me there are no advantages. My HW algorithms use no memory (cache, DRAM, or even LDs.) > Now, there are things that I am ready to pay for. E.g. preservation of > mathematical properties of original exact function. You know, of course, that incorrectly rounded SIN() and COS() do not maintain the property of SIN()^2+COS()^2 == 1.0 > I.e. if original is > monotonic on certain interval then I do want at least weak monotonicity > of approximation. My HW algorithms have a numeric proof of this maintenance. > 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. SIN(x) can be incorrectly rounded to be greater than 1.0. Still want incorrect rounding--or just a polynomial that does not have SI(X) > 1.0 ??
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-21 00:03 +0200 |
| Message-ID | <20240321000348.00004b37@yahoo.com> |
| In reply to | #383815 |
On Wed, 20 Mar 2024 20:33:44 +0000 mitchalsup@aol.com (MitchAlsup1) wrote: > Michael S wrote: > > > On Wed, 20 Mar 2024 09:54:36 -0400 > > Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > >> [ Their key insight is the idea that to get correct rounding, you > >> shouldn't try to compute the best approximation of the exact > >> result and then round, but you should instead try to compute any > >> approximation whose rounding gives the correct result. ] > >> > >> My impression was that their performance was good enough that the > >> case for not-correctly-rounded implementations becomes very weak. > >> > > > 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. > > > But in practice when we use lower (than binary64) precision we often > > care about vector performance rather than scalar. > > I.e. we care little about speed of sinf(), but want ippsTone_32f() > > as fast as possible. In case you wonder, this function is part Intel > > Performance Primitives and it is FAST. Writing correctly rounded > > function that approaches the speed of this *almost* correctly > > rounded routine (I think, for sane input ranges it's better than > > 0.55 ULP) would not be easy at all! > > I challenge ANY software version of SIN() correctly rounded or not > to compete with my <patented> HW implementations for speed (or even > power). > Before you post this response, you could as well look at what ippsTone_32f() is doing. Hint - it's not generic scalar sin(). IMHO, for long enough vector and on modern enough Intel or AMD CPU it will very easily beat any scalar-oriented binary64-oriented HW implementation of sin() or cos(). This function is not about latency. It's about throughput. AFAIR, youu were quite surprised by speed (throughput) of another IPP primitive, ippsSin_64f_A53() when I posted results of timing measurement here less than 2 yeears ago. So, before you issue a challenge, just take into account that ippsTone_32f() is both more specialized than ippsSin_64f_A53() and has much lower precision. So, while I didn't test, I expect that it is much much faster.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-20 20:26 +0000 |
| Message-ID | <45a87cfd06631ecc5820e21b8a58fe08@www.novabbs.org> |
| In reply to | #383782 |
Stefan Monnier 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). > [ Their key insight is the idea that to get correct rounding, you > shouldn't try to compute the best approximation of the exact result > and then round, but you should instead try to compute any > approximation whose rounding gives the correct result. ] This sounds like the "Minefield Method" > My impression was that their performance was good enough that the case > for not-correctly-rounded implementations becomes very weak. >>> I don't know what are/were the motivations for the people working on >>> exact transcendentals, but they have applications unrelated to the fact >>> that they're "better": the main benefit (from this here PL guy) is that >>> it gives them a reliable, reproducible semantics. >>> Bit-for-bit reproducibility makes several things much easier. >> >> Consider moving an application which uses libm from machine to machine. >> When libm is correctly rounded, there is no issue at all; not so other- >> wise. > Exactly! > [ Or should I say "Correctly rounded!"? ] > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-03-20 16:34 -0400 |
| Message-ID | <jwvy1achccw.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #383814 |
>> [ Their key insight is the idea that to get correct rounding, you
>> shouldn't try to compute the best approximation of the exact result
>> and then round, but you should instead try to compute any
>> approximation whose rounding gives the correct result. ]
>
> This sounds like the "Minefield Method"
Indeed it is.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-03-21 08:38 +0100 |
| Message-ID | <utgo6e$22viq$1@dont-email.me> |
| In reply to | #383782 |
Stefan Monnier 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). > > [ Their key insight is the idea that to get correct rounding, you > shouldn't try to compute the best approximation of the exact result > and then round, but you should instead try to compute any > approximation whose rounding gives the correct result. ] That is indeed interesting. However, it is also very interesting that they only do this for 32-bit or less. I.e. the domains for which it is almost trivially easy to verify the results by checking all possible inputs. :-) > > My impression was that their performance was good enough that the case > for not-correctly-rounded implementations becomes very weak. I agree in priniciple: If you can use polys that are not much more complicated than the min-max/cheby case, and which always round to the desired values, then that's an obvious good. ... Reading the full log2f() code, it seems that they can use double for all evaluations, and with a single (!) mantissa exception, this produces the correct results for all inputs and all rounding modes. :-) I.e. with 53 bits to work with, giving up about one ulp for the range reduction, the 52 remaining bits corresponds to 2n+6 bits available for the 5-term poly to evaluate a final float result. When asking for perfectly rounded trancendentals, with approximately the same runtime, the float case is a form of cheating, simply because current FPUs tend to run float and double at the same speed. OTOH, I'm still persuaded that for a float library, using this approach might in fact be included in the 754 standard. Doing the same for double by "simply" doing all operations with fp128 variables would definitely take significantly longer, and verification would be an "interesting" problem. (Interesting in the "multiple PhDs" domain.) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web