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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-23 14:32 +0200 |
| Message-ID | <20240223143250.000012a8@yahoo.com> |
| In reply to | #382927 |
On Fri, 23 Feb 2024 00:13:02 -0000 (UTC) "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote: > On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote: > > > > > I have a patent on doing argument reduction for sin(x) in 4 > > cycles...that is as good as Payne-Haneok argument reduction over > > -infinity..+infinity > > By a strange coincidence, I have the Payn-Hanek paper on the > top of stack of papers on my desk. Still need to internalize > the details. > Payne-Hanek is a right answer to a wrong question. In science/engineering floating-point number x represents a range [x-ULP:x+ULP] with hopefully much higher probability of being in range [x-ULP/2:x+ULP/2]. However in this reduced range probability is flat, an "exact" x is no worse and no better than any other point within this range. Which means that when we look for y=sin(x) then for scientific/engineering purposes any answer in range* [sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The right answer to the question "What is a sin() of IEEE-754 binary64 number 1e17?" is "Anything in range [-1:1]". The wise and useful answer to the same question is "You're holding it wrong". * in paragraph Sin(x) designates result calculated with infinite precision.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-02-23 20:02 +0000 |
| Message-ID | <59454a79216ece74ac3fee0e00473357@www.novabbs.org> |
| In reply to | #382940 |
Michael S wrote: > On Fri, 23 Feb 2024 00:13:02 -0000 (UTC) > "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote: >> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote: >> >> > >> > I have a patent on doing argument reduction for sin(x) in 4 >> > cycles...that is as good as Payne-Haneok argument reduction over >> > -infinity..+infinity >> >> By a strange coincidence, I have the Payn-Hanek paper on the >> top of stack of papers on my desk. Still need to internalize >> the details. >> > Payne-Hanek is a right answer to a wrong question. If someone looking for fast sin(x) you are correct, for a person looking for the best possible (correctly rounded) result, you are not. In any event I have driven that monstrosity down from 50-odd cycles to 4-- making it at least palatable. > In science/engineering floating-point number x represents a range > [x-ULP:x+ULP] with hopefully much higher probability of being in range > [x-ULP/2:x+ULP/2]. However in this reduced range probability is flat, > an "exact" x is no worse and no better than any other point within this > range. > Which means that when we look for y=sin(x) then for > scientific/engineering purposes any answer in range* > [sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The > right answer to the question "What is a sin() of IEEE-754 binary64 > number 1e17?" is "Anything in range [-1:1]". The wise and useful answer > to the same question is "You're holding it wrong". There are verification tests that know the exact value of both x and sin(x). For these uses you argument is not valid--however I am willing to grant that outside of verification, and in actual use, your argument holds as well ad the noise in the data provides. > * in paragraph Sin(x) designates result calculated with infinite > precision.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-02-23 20:38 +0000 |
| Message-ID | <uravp3$nl44$1@dont-email.me> |
| In reply to | #382944 |
On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:
> Michael S wrote:
>
>> On Fri, 23 Feb 2024 00:13:02 -0000 (UTC)
>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
>
>>> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:
>>>
>>>
>>> > I have a patent on doing argument reduction for sin(x) in 4
>>> > cycles...that is as good as Payne-Haneok argument reduction over
>>> > -infinity..+infinity
>>>
>>> By a strange coincidence, I have the Payn-Hanek paper on the top of
>>> stack of papers on my desk. Still need to internalize the details.
>>>
>>>
>> Payne-Hanek is a right answer to a wrong question.
>
> If someone looking for fast sin(x) you are correct, for a person looking
> for the best possible (correctly rounded) result, you are not. In any
> event I have driven that monstrosity down from 50-odd cycles to 4--
> making it at least palatable.
>
>> In science/engineering floating-point number x represents a range
>> [x-ULP:x+ULP] with hopefully much higher probability of being in range
>> [x-ULP/2:x+ULP/2]. However in this reduced range probability is flat,
>> an "exact" x is no worse and no better than any other point within this
>> range.
>> Which means that when we look for y=sin(x) then for
>> scientific/engineering purposes any answer in range*
>> [sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The
>> right answer to the question "What is a sin() of IEEE-754 binary64
>> number 1e17?" is "Anything in range [-1:1]". The wise and useful answer
>> to the same question is "You're holding it wrong".
>
> There are verification tests that know the exact value of both x and
> sin(x).
> For these uses you argument is not valid--however I am willing to grant
> that outside of verification, and in actual use, your argument holds as
> well ad the noise in the data provides.
Fortunately, for 32-bit single precision floating point, one can
exhaustively test single-argument functions. For the SW implementation
on FreeBSD, exhaustive testing shows
% tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0
Interval tested for sinpif: [0,8.38861e+06]
1000000 calls, 0.015453 secs, 0.01545 usecs/call
ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024
Max ulp: 0.583666 at 6.07950642e-05
% tlibm sin -fPED -x 0 -X 0x1p23 -s 0
Interval tested for sinf: [0,8.38861e+06]
1000000 calls, 0.019520 secs, 0.01952 usecs/call
ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593
Max ulp: 0.500900 at 3.68277281e+05
The speed test is for 1M values evenly distributed over
the interval. The difference in speed for sinpi vs sin
is due to the argument reduction.
Note 1: libm built with clang/llvm with only -O2 on a
AMD Phenom II X2 560 Processor (3300.14-MHz K8-class CPU).
Note 2: subnormal values for x are test not included in
the count as subnormal are tested with a different approach.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-02-23 22:29 +0000 |
| Message-ID | <9862882e1badcd541491098b47c61802@www.novabbs.org> |
| In reply to | #382947 |
Steven G. Kargl wrote:
> On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:
>> Michael S wrote:
>>
>>> On Fri, 23 Feb 2024 00:13:02 -0000 (UTC)
>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
>>
>>>> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:
>>>>
>>>>
>>>> > I have a patent on doing argument reduction for sin(x) in 4
>>>> > cycles...that is as good as Payne-Haneok argument reduction over
>>>> > -infinity..+infinity
>>>>
>>>> By a strange coincidence, I have the Payn-Hanek paper on the top of
>>>> stack of papers on my desk. Still need to internalize the details.
>>>>
>>>>
>>> Payne-Hanek is a right answer to a wrong question.
>>
>> If someone looking for fast sin(x) you are correct, for a person looking
>> for the best possible (correctly rounded) result, you are not. In any
>> event I have driven that monstrosity down from 50-odd cycles to 4--
>> making it at least palatable.
>>
>>> In science/engineering floating-point number x represents a range
>>> [x-ULP:x+ULP] with hopefully much higher probability of being in range
>>> [x-ULP/2:x+ULP/2]. However in this reduced range probability is flat,
>>> an "exact" x is no worse and no better than any other point within this
>>> range.
>>> Which means that when we look for y=sin(x) then for
>>> scientific/engineering purposes any answer in range*
>>> [sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The
>>> right answer to the question "What is a sin() of IEEE-754 binary64
>>> number 1e17?" is "Anything in range [-1:1]". The wise and useful answer
>>> to the same question is "You're holding it wrong".
>>
>> There are verification tests that know the exact value of both x and
>> sin(x).
>> For these uses you argument is not valid--however I am willing to grant
>> that outside of verification, and in actual use, your argument holds as
>> well ad the noise in the data provides.
> Fortunately, for 32-bit single precision floating point, one can
All of the numerics I have spoken about are DP (64-bit) values.
> exhaustively test single-argument functions. For the SW implementation
> on FreeBSD, exhaustive testing shows
> % tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0
> Interval tested for sinpif: [0,8.38861e+06]
> 1000000 calls, 0.015453 secs, 0.01545 usecs/call
> ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
> 0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024
> Max ulp: 0.583666 at 6.07950642e-05
> % tlibm sin -fPED -x 0 -X 0x1p23 -s 0
> Interval tested for sinf: [0,8.38861e+06]
> 1000000 calls, 0.019520 secs, 0.01952 usecs/call
> ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
> 0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593
> Max ulp: 0.500900 at 3.68277281e+05
I find it interesting that sinpi() has worse numeric error than sin().
I also find it interesting that the highest error is in the easy part
of polynomial evaluation without argument reduction whereas sin() has
its worst result in a region where significant argument reduction has
transpired.
{{Seems like another case of faster poor answers top slower correct
answers.}}
> The speed test is for 1M values evenly distributed over
> the interval. The difference in speed for sinpi vs sin
> is due to the argument reduction.
But result precision suffers nonetheless.
> Note 1: libm built with clang/llvm with only -O2 on a
> AMD Phenom II X2 560 Processor (3300.14-MHz K8-class CPU).
> Note 2: subnormal values for x are test not included in
> the count as subnormal are tested with a different approach.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-23 22:39 +0000 |
| Message-ID | <urb6qn$phho$2@dont-email.me> |
| In reply to | #382948 |
On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote: > I find it interesting that sinpi() has worse numeric error than sin(). Another argument for sticking with the simpler solution? One set of radian-specific functions plus conversion factors, instead of a separate set of unit-specific functions for every unit?
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-02-24 04:03 +0000 |
| Message-ID | <urbpps$10mal$1@dont-email.me> |
| In reply to | #382949 |
On Fri, 23 Feb 2024 22:39:19 +0000, Lawrence D'Oliveiro wrote:
> On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote:
>
>> I find it interesting that sinpi() has worse numeric error than sin().
>
> Another argument for sticking with the simpler solution? One set of
> radian-specific functions plus conversion factors, instead of a separate
> set of unit-specific functions for every unit?
Here's a counter argument for your simple conversion
factors. Changing FreeBSD's libm to return sinf(M_PI*x)
for sinpif(x), one observes
%./tlibm sinpi -f -x 0 -X 0x1p22 -PED
Interval tested for sinpif: [0,4.1943e+06]
ulp <= 0.5: 83.174% 1037372501 | 83.174% 1037372501
0.5 < ulp < 0.6: 0.937% 11690904 | 84.111% 1049063405
0.6 < ulp < 0.7: 0.689% 8587516 | 84.800% 1057650921
0.7 < ulp < 0.8: 0.497% 6200902 | 85.297% 1063851823
0.8 < ulp < 0.9: 0.323% 4023726 | 85.620% 1067875549
0.9 < ulp < 1.0: 0.157% 1952256 | 85.776% 1069827805
1.0 < ulp < 1.5: 0.347% 4332879 | 86.124% 1074160684
1.5 < ulp < 2.0: 0.247% 3083647 | 86.371% 1077244331
2.0 < ulp < 3.0: 0.360% 4491936 | 86.731% 1081736267
3.0 < ulp < 0.0: 13.269% 165496149 | 100.000% 1247232416
Max ulp: 8388278.500000 at 5.65300049e+03
% ./tlibm sinpi -f -a 5.65300049e+03
x = 5.65300049e+03f, /* 0x45b0a801 */
libm = -2.51050433e-03f, /* 0xbb248746 */
mpfr = -1.53398013e-03f, /* 0xbac90fd5 */
ULP = 8388278.50000
I can assure one of the libm and mpfr values, when x = 5653.00049,
is quite wrong.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-24 04:47 +0000 |
| Message-ID | <urbsd1$117c5$1@dont-email.me> |
| In reply to | #382965 |
On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote: > I can assure one of the libm and mpfr values, when x = 5653.00049, > is quite wrong. That’s 9 figures, but single-precision IEEE754 floats only allow about 7.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-02-24 05:27 +0000 |
| Message-ID | <urbune$11ag0$1@dont-email.me> |
| In reply to | #382966 |
On Sat, 24 Feb 2024 04:47:29 +0000, Lawrence D'Oliveiro wrote:
> On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:
>
>> I can assure one of the libm and mpfr values, when x = 5653.00049,
>> is quite wrong.
>
> That’s 9 figures, but single-precision IEEE754 floats only allow about
> 7.
ROTFL. I suggest (re-)reading the entire section
IEEE Std 754TM-2008
5.12.2 External decimal character sequences representing
finite numbers
However, I'll give you the salient part on p.32
For the purposes of discussing the limits on correctly
rounded conversion, define the following quantities:
for binary32, Pmin (binary32) = 9
...
Conversions from a supported binary format bf to an external
character sequence and back again results in a copy of the
original number so long as there are at least Pmin (bf)
significant digits specified and the rounding-direction
attributes in effect during the two conversions are round to
nearest rounding-direction attributes.
You also seem to miss that I gave you the bit pattern as
an unsigned 32-bit int. There are no extra binary digits.
At this point, I think it might be prudent for you to
read Goldberg's paper [1] and IEEE 754.
[1] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I'm done responding to your trolls and apologies other c.l.c
posters.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-24 05:48 +0000 |
| Message-ID | <20240223213938.723@kylheku.com> |
| In reply to | #382967 |
On 2024-02-24, Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> wrote: > On Sat, 24 Feb 2024 04:47:29 +0000, Lawrence D'Oliveiro wrote: > >> On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote: >> >>> I can assure one of the libm and mpfr values, when x = 5653.00049, >>> is quite wrong. >> >> That’s 9 figures, but single-precision IEEE754 floats only allow about >> 7. > > ROTFL. I suggest (re-)reading the entire section [ snip ] > for binary32, Pmin (binary32) = 9 Also, from the comp.lang.c point of view, in the C language we have FLT_DIG and FLT_DECIMAL_DIG in <float.h>. On IEEE 754 systems these are 6 and 9. FLT_DIG gives you, roughly speaking, how many decimal digits of precision a float can preserve in the decimal -> float -> decimal conversion sequence FLT_DECIMAL_DIG indicates how many digits are required to exactly preserve a float value in decimal form: float -> decimal -> float. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-24 05:38 +0000 |
| Message-ID | <urbvdd$11l69$1@dont-email.me> |
| In reply to | #382965 |
On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote: > % ./tlibm sinpi -f -a 5.65300049e+03 > x = 5.65300049e+03f, /* 0x45b0a801 */ > libm = -2.51050433e-03f, /* 0xbb248746 */ > mpfr = -1.53398013e-03f, /* 0xbac90fd5 */ > ULP = 8388278.50000 > > I can assure one of the libm and mpfr values, when x = 5653.00049, > is quite wrong. They’re all wrong. Python says (in double-precision), that math.sin(5653.00049) is -0.9566595256716378. Even GCC’s sinf function says the value is -0.9565167, which is only a slight discrepancy in the fourth decimal place, so even in single- precision it is doing a darn sight better than you have managed above. So where is there a version of the code you’re using, using different angle units, that gets closer to the right answer?
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-02-24 06:13 +0000 |
| Message-ID | <urc1f6$11u41$1@dont-email.me> |
| In reply to | #382968 |
On Sat, 24 Feb 2024 05:38:53 +0000, Lawrence D'Oliveiro wrote: > On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote: > >> % ./tlibm sinpi -f -a 5.65300049e+03 >> x = 5.65300049e+03f, /* 0x45b0a801 */ >> libm = -2.51050433e-03f, /* 0xbb248746 */ >> mpfr = -1.53398013e-03f, /* 0xbac90fd5 */ >> ULP = 8388278.50000 >> >> I can assure one of the libm and mpfr values, when x = 5653.00049, >> is quite wrong. > > They’re all wrong. Python says (in double-precision), that > math.sin(5653.00049) is -0.9566595256716378. > > Even GCC’s sinf function says the value is -0.9565167, which is only a > slight discrepancy in the fourth decimal place, so even in single- > precision it is doing a darn sight better than you have managed above. > > So where is there a version of the code you’re using, using different > angle units, that gets closer to the right answer? sin(x) is not sinpi(x). The conversion factor that you're missing is M_PI as in sinpi(x) = sin(M_PI*x). The whole point of the half-cycle trig functions is that one does not need to do the multiplication by pi, or more importantly the argument reduction modulo pi. % ./tlibm sin -f -a 5.65300049e+3 x = 5.65300049e+03f, /* 0x45b0a801 */ libm = -9.56659019e-01f, /* 0xbf74e79b */ mpfr = -9.56659019e-01f, /* 0xbf74e79b */ ULP = 0.10338 -- steve
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-03-14 17:15 +0000 |
| Message-ID | <9fcb5c6dc0bc30fadff42be770fdb896@www.novabbs.org> |
| In reply to | #382970 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2024-02-23 23:20 +0000 |
| Message-ID | <urb97g$pkrs$1@dont-email.me> |
| In reply to | #382948 |
On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote:
> Steven G. Kargl wrote:
>
>> On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:
>
>>> Michael S wrote:
>>>
>>>> On Fri, 23 Feb 2024 00:13:02 -0000 (UTC)
>>>> "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
>>>
>>>>> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:
>>>>>
>>>>>
>>>>> > I have a patent on doing argument reduction for sin(x) in 4
>>>>> > cycles...that is as good as Payne-Haneok argument reduction over
>>>>> > -infinity..+infinity
>>>>>
>>>>> By a strange coincidence, I have the Payn-Hanek paper on the top of
>>>>> stack of papers on my desk. Still need to internalize the details.
>>>>>
>>>>>
>>>> Payne-Hanek is a right answer to a wrong question.
>>>
>>> If someone looking for fast sin(x) you are correct, for a person
>>> looking for the best possible (correctly rounded) result, you are not.
>>> In any event I have driven that monstrosity down from 50-odd cycles to
>>> 4-- making it at least palatable.
>>>
>>>> In science/engineering floating-point number x represents a range
>>>> [x-ULP:x+ULP] with hopefully much higher probability of being in
>>>> range [x-ULP/2:x+ULP/2]. However in this reduced range probability is
>>>> flat, an "exact" x is no worse and no better than any other point
>>>> within this range.
>>>> Which means that when we look for y=sin(x) then for
>>>> scientific/engineering purposes any answer in range*
>>>> [sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The
>>>> right answer to the question "What is a sin() of IEEE-754 binary64
>>>> number 1e17?" is "Anything in range [-1:1]". The wise and useful
>>>> answer to the same question is "You're holding it wrong".
>>>
>>> There are verification tests that know the exact value of both x and
>>> sin(x).
>>> For these uses you argument is not valid--however I am willing to
>>> grant that outside of verification, and in actual use, your argument
>>> holds as well ad the noise in the data provides.
>
>> Fortunately, for 32-bit single precision floating point, one can
>
> All of the numerics I have spoken about are DP (64-bit) values.
Sure, but it isn't possible to exhaustively DP on current hardware
(available to me). Simple testing can give one a warm fuzzy feeling.
With 10M values in the range [0,0x1p53], the SW sinpi seems to be better
than the SW sin.
% tlibm sin -d -x 0 -X 0x1p53 -N 10 -s 0
Interval tested for sin: [0,9.0072e+15]
10000000 calls, 2.594275 secs, 0.25943 usecs/call
count: 10000000
xm = 3.4119949728897955e+15, /* 0x43283e61, 0xf8ab4587 */
libm = 7.2135591711063873e-01, /* 0x3fe71559, 0x0118855e */
mpfr = 7.2135591711063862e-01, /* 0x3fe71559, 0x0118855d */
ULP = 0.77814
% tlibm sinpi -d -x 0 -X 0x1p53 -N 10 -s 0
Interval tested for sinpi: [0,9.0072e+15]
10000000 calls, 0.184541 secs, 0.01845 usecs/call
count: 10000000
xm = 1.5384297865527400e+12, /* 0x42766318, 0xf99b8bd7 */
libm = 7.2898962872051931e-01, /* 0x3fe753e2, 0x0ecf4a3e */
mpfr = 7.2898962872051942e-01, /* 0x3fe753e2, 0x0ecf4a3f */
ULP = 0.69476
Note, the timing difference is again dominated by argument reduction.
Also note, that each of the above tests took ~180 cpu seconds. At
the moment, tlibm will not use multiple cores or cpus on other nodes.
>> exhaustively test single-argument functions. For the SW implementation
>> on FreeBSD, exhaustive testing shows
>
>> % tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0 Interval tested for sinpif:
>> [0,8.38861e+06]
>> 1000000 calls, 0.015453 secs, 0.01545 usecs/call
>> ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
>> 0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024 Max ulp:
>> 0.583666 at 6.07950642e-05
>
>> % tlibm sin -fPED -x 0 -X 0x1p23 -s 0 Interval tested for sinf:
>> [0,8.38861e+06]
>> 1000000 calls, 0.019520 secs, 0.01952 usecs/call
>> ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
>> 0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593 Max ulp:
>> 0.500900 at 3.68277281e+05
>
> I find it interesting that sinpi() has worse numeric error than sin().
>
> I also find it interesting that the highest error is in the easy part of
> polynomial evaluation without argument reduction whereas sin() has its
> worst result in a region where significant argument reduction has
> transpired.
>
> {{Seems like another case of faster poor answers top slower correct
> answers.}}
For my purposes, a max ulp 0.538 is good enough. The time needed
to reduce this to 0.5009 is better spent on other unimplemented
libm functions in Freebsd's libm or implemented functions with
much worse ULP
>> The speed test is for 1M values evenly distributed over the interval.
>> The difference in speed for sinpi vs sin is due to the argument
>> reduction.
>
> But result precision suffers nonetheless.
Argument reduction itself isn't the culprit. Go read the FreeBSD source
code. What is done once one has the reduced argument is the issue. I
suspect that any patch you come up with would be gladly accepted.
--
steve
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-23 22:39 +0000 |
| Message-ID | <urb6rt$phho$3@dont-email.me> |
| In reply to | #382947 |
On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote: > Note 2: subnormal values ... Why did they bring in the term “subnormal”, anyway? What was wrong with “denormalized”?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-23 23:16 +0000 |
| Message-ID | <878r3abwkv.fsf@bsb.me.uk> |
| In reply to | #382950 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote: > >> Note 2: subnormal values ... > > Why did they bring in the term “subnormal”, anyway? What was wrong with > “denormalized”? Greater clarity maybe? After all, the two terms do mean different things. In IEEE FP only subnormals can exist, but it surely helps to be able to talk about the difference. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-23 23:44 +0000 |
| Message-ID | <urbaki$qb3j$1@dont-email.me> |
| In reply to | #382952 |
On Fri, 23 Feb 2024 23:16:32 +0000, Ben Bacarisse wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote: >> >>> Note 2: subnormal values ... >> >> Why did they bring in the term “subnormal”, anyway? What was wrong with >> “denormalized”? > > Greater clarity maybe? After all, the two terms do mean different > things. In IEEE FP only subnormals can exist, but it surely helps to be > able to talk about the difference. I thought they were the same thing: extra numbers inserted in the gap between the normalized number closest to zero on each side, to allow for gradual underflow.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-24 01:15 +0000 |
| Message-ID | <8734tibr1t.fsf@bsb.me.uk> |
| In reply to | #382955 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Fri, 23 Feb 2024 23:16:32 +0000, Ben Bacarisse wrote: > >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> >>> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote: >>> >>>> Note 2: subnormal values ... >>> >>> Why did they bring in the term “subnormal”, anyway? What was wrong with >>> “denormalized”? >> >> Greater clarity maybe? After all, the two terms do mean different >> things. In IEEE FP only subnormals can exist, but it surely helps to be >> able to talk about the difference. > > I thought they were the same thing: extra numbers inserted in the gap > between the normalized number closest to zero on each side, to allow for > gradual underflow. Those are subnormal. They are smaller (in magnitude) than the smallest normal. Denormals are simply representations with leading zeros. IEEE FP's implicit leading 1 means these (denormals that are not subnormal) can't exist in that representation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-24 01:19 +0000 |
| Message-ID | <urbg72$rbo3$1@dont-email.me> |
| In reply to | #382956 |
On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> I thought they were the same thing: extra numbers inserted in the gap >> between the normalized number closest to zero on each side, to allow >> for gradual underflow. > > Those are subnormal. They are smaller (in magnitude) than the smallest > normal. Denormals are simply representations with leading zeros. IEEE > FP's implicit leading 1 means these (denormals that are not subnormal) > can't exist in that representation. So in IEEE754, they are the same thing. Which is what I thought. So you don’t really need two terms for them. Particularly when one of them has certain undesirable ... connotations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-24 01:27 +0000 |
| Message-ID | <87wmquaby7.fsf@bsb.me.uk> |
| In reply to | #382957 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote: > >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> >>> I thought they were the same thing: extra numbers inserted in the gap >>> between the normalized number closest to zero on each side, to allow >>> for gradual underflow. >> >> Those are subnormal. They are smaller (in magnitude) than the smallest >> normal. Denormals are simply representations with leading zeros. IEEE >> FP's implicit leading 1 means these (denormals that are not subnormal) >> can't exist in that representation. > > So in IEEE754, they are the same thing. No. I am pretty sure you understand what's been said so you must be arguing for the sake of it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-24 01:42 +0000 |
| Message-ID | <20240223174153.703@kylheku.com> |
| In reply to | #382958 |
On 2024-02-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote: >> >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>> >>>> I thought they were the same thing: extra numbers inserted in the gap >>>> between the normalized number closest to zero on each side, to allow >>>> for gradual underflow. >>> >>> Those are subnormal. They are smaller (in magnitude) than the smallest >>> normal. Denormals are simply representations with leading zeros. IEEE >>> FP's implicit leading 1 means these (denormals that are not subnormal) >>> can't exist in that representation. >> >> So in IEEE754, they are the same thing. > > No. I am pretty sure you understand what's been said so you must be > arguing for the sake of it. I have only bicycles in my garage, so in my garage, "bicycles" and "vehicles" are the same thing, not just the same set. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 5 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