Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382888 > unrolled thread

Radians Or Degrees?

Back to article view | Back to comp.lang.c

Contents

  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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9  Next page →

#383001

On Sat, 24 Feb 2024 19:26:53 -0800, Chris M. Thomasson wrote:

> think of the following interesting aspect:

One of many. Have you read the paper “What Every Computer Scientist Should 
Know About Computer Arithmetic”? Among the examples, it looks at the well-
known formula for the quadratic equation:

    -b ± sqrt(b² - 4ac)
    -------------------
            2a

and considers cases where this will not work well, and where you should 
use the alternative form

            2c
    -------------------
    -b ± sqrt(b² - 4ac)

instead. (Which has its own cases where it produces poor results, but 
luckily they don’t overlap those for the first form.)

[toc] | [prev] | [next] | [standalone]

#383912

On 2/24/2024 7:26 PM, Chris M. Thomasson wrote:
> On 2/24/2024 2:52 PM, Lawrence D'Oliveiro wrote:
>> On Sat, 24 Feb 2024 12:40:52 -0800, Chris M. Thomasson wrote:
>>
[...]
> think of the following interesting aspect:
> 
> https://forums.parallax.com/discussion/147522/dog-leg-hypotenuse-approximation
> 
> Vs "needing" to get much more accurate results, for say medical imaging 
> wrt volumetric renders...


Another "high cycle" fractal of mine that benefits from higher 
precision, under iteration:

https://paulbourke.net/fractals/cubicjulia

[toc] | [prev] | [next] | [standalone]

#382932

Steven G. Kargl wrote:

> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:

>> Michael S wrote:
>> 
>>> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> 
>>>> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>>>> 
>>>> > Apparently, you missed the part about argument reduction.  For
>>>> > sinpi(x), it is fairly easy to reduce x = n + r with n an integer
>>>> > and r in [0,1). 
>> 
>> You are better off with r in [-½,+½]

> Partial implementation details for single precision C code (trying
> to keep this on topic for c.l.c) are at 
> https://cgit.freebsd.org/src/tree/lib/msun/src/s_sinpif.c

> One uses sinpi(-|x|) = -sinpi(|x|), which natually gets one to
> r = x - floor(x) in [0,1).  One then uses kernels for sin() and
> cos() to do the actual computation.

> r in [0,0.25) is ksin(r).
> r in [0.25,0.5) is kcos(0.5-r).
> r in [0.5,0.75) is kcos(r - 0.5).
> r in [0.75,1) is ksin(1 - r).

By "better off" I mean you have ½-bit of greater reduced argument precision
when the reduced argument is centered on zero.

>>>>   For the extended interval, x in [0,2^23], there are
>>>> > roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
>>>> > There are no such values for sin(x), and argument reduction for
>>>> > sin(x) is much more involved. 
>> 
>> 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. 

Here is the version found in the SUN transcendentals::

static void ReduceFull(double *xp, int *a, double x)
{
	     Double X = { x };
	     int ec = X.s.exponent - (1023+33);
	     int k = (ec + 26) * (607*4) >> 16;
	     int m = 27*k - ec;
	     int offset = m >> 3;
	     x *= 0x1p-400;
	     double xDekker = x * (0x1p27 + 1);
	     double x0 = xDekker - (xDekker - x);
	     double x1 = x - x0;
             const double *p0 = &TwoOverPiWithOffset[offset][k]; // 180 DP FP numbers
	     const double fp0 = p0[0];
	     const double fp1 = p0[1];
	     const double fp2 = p0[2];
	     const double fp3 = p0[3];
	     const double f0 = x1 * fp0 + fp1 * x0;
	     double f = x1 * fp1 + fp2 * x0;
	     const double fi = f0 + f;
	     static const double IntegerBias = 0x1.8p52;
	     Double Fi = { fi + IntegerBias };
			     *a = Fi.s.significand2;
	     double fint = Fi.d - IntegerBias;
	     const double fp4 = p0[4];
	     const double fp5 = p0[5];
	     const double fp6 = p0[6];
	     f = f0 - fint + f;
	     f += x1 * fp2 + fp3 * x0;
	     f += x1 * fp3 + fp4 * x0;
	     f += x1 * fp4 + fp5 * x0;
	     f += x1 * fp5 + fp6 * x0;
	     *xp = f * 0x3.243F6A8885A3p-1;
}

Which I can do in 4 cycles in HW !! {{I happen to have this on hand to explain how
I can do this in HW in 4 cycles......}}

I should also note that the conversion of f back into *xp looses ¼-bit of precision.


> (much trimmed for brevity) 


>>> In digital signal processing circle-based units are pretty much always
>>> more natural than radians.
>>> For specific case of 1/2 circle, I can't see where it can be used
>>> directly.
>>> From algorithmic perspective, full circle looks like the most obvious
>>> choice.
>>> From [binary floating point] numerical properties perspective, 1/8th of
>>> the circle (==pi/4 radians = 45 degrees) is probably the best option
>>> for a library routine, because for sin() its derivative at 0 is closest
>>> to 1 among all powers of two which means that loss of precision
>>> near 0 is very similar for input and for output. But this advantage
>>> does not sound like particularly big deal.
>> 
>> I should remind that my patents include methods for calculating sin()
>> and cos() in 18 cycles, sinpi() and cospi() in 14 cycles while achieving
>> an accuracy n the 0.5002-bits of error. All of this is in HW, and all 
>> carried out in precision wider than IEEE 754 with a bunch of HW tricks
>> not available to SW.
>> 
>> At this performance level, let the algorithms wanting pi based trigonometry
>> have it and those wanting unit based trigonometry have it too. Let program-
>> mers use what is easiest for them.

> Agreed a programmer should use what is required by the problem
> that they are solving.  I'll note that SW implementations have
> their sets of tricks (e.g., use of double-double arithmetic to
> achieve double precision).

To get near IEEE desired precision, one HAS TO use more than 754 precision.

[toc] | [prev] | [next] | [standalone]

#382938

MitchAlsup1 wrote:
> Steven G. Kargl wrote:
>> Agreed a programmer should use what is required by the problem
>> that they are solving.  I'll note that SW implementations have
>> their sets of tricks (e.g., use of double-double arithmetic to
>> achieve double precision).
> 
> To get near IEEE desired precision, one HAS TO use more than 754 precision.

There are groups who have shown that exactly rounded trancendental 
functions are in fact achievable with maybe 3X reduced performance.

There is a suggestion on the table to make that a (probably optional 
imho) feature for an upcoming ieee754 revision.

Terje

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

[toc] | [prev] | [next] | [standalone]

#383605

On Fri, 23 Feb 2024 11:10:00 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> MitchAlsup1 wrote:
> > Steven G. Kargl wrote:  
> >> Agreed a programmer should use what is required by the problem
> >> that they are solving.  I'll note that SW implementations have
> >> their sets of tricks (e.g., use of double-double arithmetic to
> >> achieve double precision).  
> > 
> > To get near IEEE desired precision, one HAS TO use more than 754
> > precision.  
> 
> There are groups who have shown that exactly rounded trancendental 
> functions are in fact achievable with maybe 3X reduced performance.
>

At which cost in tables sizes?


> There is a suggestion on the table to make that a (probably optional 
> imho) feature for an upcoming ieee754 revision.
> 
> Terje
> 

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.

The definition of 'exact' should be:
For any finite-precision function foo(x) lets designate the same
mathematical function calculated with infinite precision as Foo(x).
Let's designate an operation of rounding of infinite-precision number to
desired finite precision as Rnd(). Rounding is done in to-nearest mode.
Unlike in the case of basic operations, ties are allowed to be broken in
any direction.
The result of y=foo(x) for finite-precision number x considered
exact if *at least one* two conditions is true:
(1=Y-clause) Rnd(Foo(x)) == y
(2=X-clause) There exist an infinite precision number X for which
both Foo(X) == y and Rnd(X) == x.

As follows from the (2), it is possible and not uncommon that more
than one finite-precision number y is accepted exact result of foo(x).

If Committee omits the 2nd clause then the whole proposition will be not
just not useful, but harmful.

[toc] | [prev] | [next] | [standalone]

#383608

Michael S wrote:

> On Fri, 23 Feb 2024 11:10:00 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:

>> MitchAlsup1 wrote:
>> > Steven G. Kargl wrote:  
>> >> Agreed a programmer should use what is required by the problem
>> >> that they are solving.  I'll note that SW implementations have
>> >> their sets of tricks (e.g., use of double-double arithmetic to
>> >> achieve double precision).  
>> > 
>> > To get near IEEE desired precision, one HAS TO use more than 754
>> > precision.  
>> 
>> There are groups who have shown that exactly rounded trancendental 
>> functions are in fact achievable with maybe 3X reduced performance.
>>

> At which cost in tables sizes?


>> There is a suggestion on the table to make that a (probably optional 
>> imho) feature for an upcoming ieee754 revision.
>> 
>> Terje
>> 

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

> The definition of 'exact' should be:
> For any finite-precision function foo(x) lets designate the same
> mathematical function calculated with infinite precision as Foo(x).
> Let's designate an operation of rounding of infinite-precision number to
> desired finite precision as Rnd(). Rounding is done in to-nearest mode.
> Unlike in the case of basic operations, ties are allowed to be broken in
> any direction.
> The result of y=foo(x) for finite-precision number x considered
> exact if *at least one* two conditions is true:
> (1=Y-clause) Rnd(Foo(x)) == y
> (2=X-clause) There exist an infinite precision number X for which
> both Foo(X) == y and Rnd(X) == x.

In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

> As follows from the (2), it is possible and not uncommon that more
> than one finite-precision number y is accepted exact result of foo(x).

> If Committee omits the 2nd clause then the whole proposition will be not
> just not useful, but harmful.

An interesting side effect of greater intermediate precision is the lack
of need to round prior to the final result. Thus, my sin(x) over its
entire calculation suffers exactly 1 rounding. Payne & Hanek does not
have this prperty.

[toc] | [prev] | [next] | [standalone]

#383609

And thirdly::

Let us postulate that the reduced argument r is indeed calculated with 0.5ULP
error.

What makes you think you can calculate the polynomial without introducing
any more error ??

[toc] | [prev] | [next] | [standalone]

#383635

MitchAlsup1 wrote:
> And thirdly::
> 
> Let us postulate that the reduced argument r is indeed calculated with 
> 0.5ULP
> error.
> 
> What makes you think you can calculate the polynomial without introducing
> any more error ??

It should be obvious that any argument reduction step must return a 
value with significantly higher precision than the input(s), and that 
this higher precision value is then used in any polynomial evaluation.

With careful setup, it is very often possible to reduce the amount of 
extended-procision work needed to just one or two steps, i.e. for the 
classic Taylor sin(x) series, with x fairly small, the x^3 and higher 
terms can make do with double precision, so that the final step is to 
add the two parts of the leading x term: First the trailing part and 
then when adding the upper 53 bits of x you get a single rounding at 
this stage.

This is easier and better when done with 64-bit fixed-point values, 
augemented with a few 128-bit operations.

Terje

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

[toc] | [prev] | [next] | [standalone]

#383610

On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:

> Michael S wrote:
> 
>> (2=X-clause) There exist an infinite precision number X for which
>> both Foo(X) == y and Rnd(X) == x.
> 
> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.

When you say “RND”, I think of a bad random-number generator found in 
various implementations of BASIC.

[toc] | [prev] | [next] | [standalone]

#383612

On 3/14/2024 1:30 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:
> 
>> Michael S wrote:
>>
>>> (2=X-clause) There exist an infinite precision number X for which
>>> both Foo(X) == y and Rnd(X) == x.
>>
>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
> 
> No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.
> 
> When you say “RND”, I think of a bad random-number generator found in
> various implementations of BASIC.

PRNG, an LGC? Fwiw, check this shit out:

https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ

;^D

[toc] | [prev] | [next] | [standalone]

#383613

Lawrence D'Oliveiro wrote:

> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:

>> Michael S wrote:
>> 
>>> (2=X-clause) There exist an infinite precision number X for which
>>> both Foo(X) == y and Rnd(X) == x.
>> 
>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

> No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.

You have just selected yourself as someone I will never reply to again.

> When you say “RND”, I think of a bad random-number generator found in 
> various implementations of BASIC.

[toc] | [prev] | [next] | [standalone]

#383614

On 3/14/2024 3:19 PM, MitchAlsup1 wrote:
> Lawrence D'Oliveiro wrote:
> 
>> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:
> 
>>> Michael S wrote:
>>>
>>>> (2=X-clause) There exist an infinite precision number X for which
>>>> both Foo(X) == y and Rnd(X) == x.
>>>
>>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
> 
>> No idea why that’s relevant. Michael S was talking about “Rnd”, not 
>> “RND”.
> 
> You have just selected yourself as someone I will never reply to again.

It might be an AI? Just have a very strange feeling... Humm...


> 
>> When you say “RND”, I think of a bad random-number generator found in 
>> various implementations of BASIC.

[toc] | [prev] | [next] | [standalone]

#383615

On 3/14/2024 3:21 PM, Chris M. Thomasson wrote:
> On 3/14/2024 3:19 PM, MitchAlsup1 wrote:
[...]

An AI set on ass mode?

[toc] | [prev] | [next] | [standalone]

#383636

On Thu, 14 Mar 2024 17:34:57 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
> 
> > (2=X-clause) There exist an infinite precision number X for which
> > both Foo(X) == y and Rnd(X) == x.  
> 
> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
> 

No, we are not.

> > As follows from the (2), it is possible and not uncommon that more
> > than one finite-precision number y is accepted exact result of
> > foo(x).  
> 
> > If Committee omits the 2nd clause then the whole proposition will
> > be not just not useful, but harmful.  
> 
> An interesting side effect of greater intermediate precision is the
> lack of need to round prior to the final result. Thus, my sin(x) over
> its entire calculation suffers exactly 1 rounding. Payne & Hanek does
> not have this prperty.

Which does not help to recover precision lost during rounding of x
that happened before your wonderful instruction.

[toc] | [prev] | [next] | [standalone]

#383634

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.

Actually using and depending upon the result is more stupid.

OTOH, it is and have always been, a core principle of ieee754 that basic 
operations (FADD/FSUB/FMUL/FDIV/FSQRT) shall assume that the inputs are 
exact (no fractional ulp uncertainty), and that we from that starting 
point must deliver a correctly rounded version of the infinitely precise 
exact result of the operation.

Given the latter, it is in fact very tempting to see if that basic 
result rule could be applied to more of the non-core operations, but I 
cannot foresee any situation where I would use it myself: If I find 
myself in a situation where the final fractional ulp is important, then 
I would far rather switch to doing the operation in fp128.

Terje

Michael S wrote:
> On Fri, 23 Feb 2024 11:10:00 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> 
>> MitchAlsup1 wrote:
>>> Steven G. Kargl wrote:
>>>> Agreed a programmer should use what is required by the problem
>>>> that they are solving.  I'll note that SW implementations have
>>>> their sets of tricks (e.g., use of double-double arithmetic to
>>>> achieve double precision).
>>>
>>> To get near IEEE desired precision, one HAS TO use more than 754
>>> precision.
>>
>> There are groups who have shown that exactly rounded trancendental
>> functions are in fact achievable with maybe 3X reduced performance.
>>
> 
> At which cost in tables sizes?
> 
> 
>> There is a suggestion on the table to make that a (probably optional
>> imho) feature for an upcoming ieee754 revision.
>>
>> Terje
>>
> 
> 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.
> 
> The definition of 'exact' should be:
> For any finite-precision function foo(x) lets designate the same
> mathematical function calculated with infinite precision as Foo(x).
> Let's designate an operation of rounding of infinite-precision number to
> desired finite precision as Rnd(). Rounding is done in to-nearest mode.
> Unlike in the case of basic operations, ties are allowed to be broken in
> any direction.
> The result of y=foo(x) for finite-precision number x considered
> exact if *at least one* two conditions is true:
> (1=Y-clause) Rnd(Foo(x)) == y
> (2=X-clause) There exist an infinite precision number X for which
> both Foo(X) == y and Rnd(X) == x.
> 
> As follows from the (2), it is possible and not uncommon that more
> than one finite-precision number y is accepted exact result of foo(x).
> 
> If Committee omits the 2nd clause then the whole proposition will be not
> just not useful, but harmful.
> 


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

[toc] | [prev] | [next] | [standalone]

#383637

On Fri, 15 Mar 2024 11:23:45 +0100
Terje Mathisen <terje.mathisen@tmsw.no> 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.
> 
> Actually using and depending upon the result is more stupid.
> 
> OTOH, it is and have always been, a core principle of ieee754 that
> basic operations (FADD/FSUB/FMUL/FDIV/FSQRT) shall assume that the
> inputs are exact (no fractional ulp uncertainty), and that we from
> that starting point must deliver a correctly rounded version of the
> infinitely precise exact result of the operation.
> 
> Given the latter, it is in fact very tempting to see if that basic 
> result rule could be applied to more of the non-core operations, but
> I cannot foresee any situation where I would use it myself: If I find 
> myself in a situation where the final fractional ulp is important,
> then I would far rather switch to doing the operation in fp128.
> 
> Terje
>

To make it less tempting, you could try to push for inclusion of
rsqrt() into basic set. Long overdue, IMHO.

Right now, I can't think of any other transcendental that I really want
to elevate to higher status. It seems to me that elevation of log2(x)
and of 2**x will do no harm, but I am not sure about usefulness.

[toc] | [prev] | [next] | [standalone]

#383646

Michael S wrote:

> To make it less tempting, you could try to push for inclusion of
> rsqrt() into basic set. Long overdue, IMHO.

Many Newton-Raphson iterations converge more rapidly with RSQRT than
with SQRT, for reasons I never looked that deeply into.

> Right now, I can't think of any other transcendental that I really want
> to elevate to higher status. It seems to me that elevation of log2(x)
> and of 2**x will do no harm, but I am not sure about usefulness.

Ln2 and EXP2 are the basis of My 66000 log and EXP families, performed in
HW function unit.

Ln2 has the property that a binade [1..2) maps directly to another binade
[2..4); exp2 has a similar property. Ln2 is easier to get good accuracy
from than Ln or Log as a starting point. But in any event:: you are always 
within a high precision multiply of the correct result = round(53×106);

[toc] | [prev] | [next] | [standalone]

#383654

MitchAlsup1 wrote:
> Michael S wrote:
> 
>> To make it less tempting, you could try to push for inclusion of
>> rsqrt() into basic set. Long overdue, IMHO.
> 
> Many Newton-Raphson iterations converge more rapidly with RSQRT than
> with SQRT, for reasons I never looked that deeply into.

The classic NR iteration for rsqrt() uses only fmul & fadd/fsub, while 
the naive sqrt() version needs a divide in every iteration.

Personally I prefer to use the y = rsqrt(x) form and then just multiply 
by x in the end:

   y = sqrt(x) = x/sqrt(x) = rsqrt(x)*x

In order to get the rounding correct from this form you can probably 
just square the final result and compare this with the original input?
> 
>> Right now, I can't think of any other transcendental that I really want
>> to elevate to higher status. It seems to me that elevation of log2(x)
>> and of 2**x will do no harm, but I am not sure about usefulness.
> 
> Ln2 and EXP2 are the basis of My 66000 log and EXP families, performed in
> HW function unit.
> 
> Ln2 has the property that a binade [1..2) maps directly to another binade
> [2..4); exp2 has a similar property. Ln2 is easier to get good accuracy
> from than Ln or Log as a starting point. But in any event:: you are 
> always within a high precision multiply of the correct result = 
> round(53×106);

Exactly the same reasoning I used to compute rsqrt() over the [1.0 - 
4.0> range, or (simplifying the exp logic) over [0.5 - 2.0> so that the 
last exp bit maps to the first vs second half of the range. Back before 
we got approximate rsqrt() lookup opcodes, I wrote code that took the 
last exp bit and the first n mantissa bits and looked up an optimal 
starting point for that value + 0.5 ulp. Getting 11-12 bits this way 
means approximatly correct float after a single iteration and useful 
double after two.

Terje


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

[toc] | [prev] | [next] | [standalone]

#383638

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. :^)

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]

#383639

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. :^)
> 
> Now, wrt the results, arbitrary precision for trig is useful, in say... 
> Deep fractal zooms...

Say I want at least 30 digits of precision for a certain calculation of 
complex numbers at a certain zoom level. Along the lines of trying to 
match convergents of continued fractions, take pi:

3.1415926535897932384...

two digits of decimal precision:

22/7 = 3.14_28571428571428571428571428571


three digits of decimal precision:

333/106 = 3.1415_094339622641509433962264151


six digits of decimal precision:

355/113 = 3.141592_9203539823008849557522124

On and on...

Well...


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

Page 2 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