Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: Radians Or Degrees? Date: Sun, 17 Mar 2024 14:15:27 +0200 Organization: A noiseless patient Spider Lines: 81 Message-ID: <20240317141527.00002a11@yahoo.com> References: <20240222015920.00000260@yahoo.com> <20240222233838.0000572f@yahoo.com> <3b2e86cdb0ee8785b4405ab10871c5ca@www.novabbs.org> <936a852388e7e4414cb7e529da7095ea@www.novabbs.org> <20240314112655.000011f8@yahoo.com> <87wmq32o26.fsf@nosuchdomain.example.com> <8de6385435bbdb0695a7ff213653f345@www.novabbs.org> <20240316190815.000005a2@yahoo.com> <87o7bd3guo.fsf@nosuchdomain.example.com> <20240317110621.00005b30@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: dont-email.me; posting-host="fd62a22e31fcf9828d4eedf77229489a"; logging-data="3664868"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/45Vrm0e9030kOUpLTy1zAuEW33xV0zB0=" Cancel-Lock: sha1:gd4PJ8Q/pJx2udXLJLBVtwcIO8k= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 5314 On Sun, 17 Mar 2024 10:59:46 +0000 bart wrote: > On 17/03/2024 09:06, Michael S wrote: > > On Sat, 16 Mar 2024 16:19:11 -0700 > > Keith Thompson wrote: =20 >=20 > > As written, your example does not emphasize that the problem has > > nothing to do with implementation of sinX() library routine. > > It's best illustrated by followup conversation with bart, IMHO 100% > > O.T. =20 >=20 >=20 > Actually, the thread topic is the more basic one of whether angles to=20 > these functions should be specified as degrees or radians. >=20 Degrees can be seen as a form of turn=3D=3Dcircle-based units, but for most purposes except interaction with user they are not quite as convenient as plain turns or than turns multiplied by some negative power of two.=20 > In answer to that, I decided long ago (in my language designs) to > keep them as radians, but allow degrees for constants if written in > one of these styles like this: >=20 > sin(30=C2=B0) + cos(60 deg) >=20 > Because, once they're inside a variable: >=20 > sin(alpha) + cos(beta) >=20 > then the unit used is irrelevant. >=20 > As for the value returned from sin() etc, I haven't worried about > that since last century. >=20 > Except briefly more recently when I had an arbitrary precision > floating point library and considered whether to add such functions, > but concluded I didn't have the right skills, experience (of using=20 > ultra-high precision trig functions) or motivation. >=20 > The first problem was: exactly how accurately should it be generated.=20 > With ieee754 it's easy, you only have 53 binary digits to fill. >=20 > In my (decimal) library, the default precision for a calculation like=20 > 1.0/3.0 is typically set up to 500 decimal digits, or about 1600 > bits, otherwise it will keep going forever (the theoretical limit is > 19 billion decimal digits, or 64 billion bits). >=20 > The second problem was, how do you even calculate sin(x) so that it=20 > converges to that accuracy within a reasonable amount of time? The=20 > Taylor series that I used to use wouldn't cut it. There exist better series than Taylor, but in case of high-precision sin()/cos() they are not MUCH better. Typically, just one term shorter than Taylor for a given precision, at most two terms. And quite often this additional terms can be done with lower precision (e.g. IEEE binary) so in terms of execution time the difference is close to noise. The key to faster high-prec sin()/cos() is breaking quarter-circle of input into more ranges. For 1600 bits you would almost certainly want to do it hierarchically. I never dealt with such high precision myself so has no intuition about number of levels. For (much) lower precision I used 6 or 7 bits per level of hierarchy, but with 1600 bits I'd think that it makes sense to use fewer bit per level in order to keep total size of the tables within limits of 2nd-level cache of typical CPU. May be, 7 bits on few higher levels and then 1 or 2 bits for the rest? Now, too many levels of hierarchy cause the problems of their own, specifically, intermediate calculations would likely need higher precision. The trade offs are not simple :( >=20 > (Dealing with inputs that are extreme multiples of +/- 2pi radians > would be an additional difficulty.) >=20 > I decided not to bother with transcendental functions. >=20 You can solve most of your problems by integrating MPFR into your runtime.