Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c,comp.arch Subject: Re: Radians Or Degrees? Date: Sat, 16 Mar 2024 19:57:17 -0700 Organization: None to speak of Lines: 110 Message-ID: <87frwp36r6.fsf@nosuchdomain.example.com> References: <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> <87jzm13af9.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: dont-email.me; posting-host="bef1352e676cdb1e0584d8972e1644aa"; logging-data="3494669"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RxFqhwg0R3Mq/oRJs3oXd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:VK1vRyexfuGU6y+CungcXa5OKxg= sha1:WsTzHHkmXoM0n4NvCq9V1Z/RQyo= Xref: csiph.com comp.lang.c:383671 comp.arch:105408 bart writes: > On 17/03/2024 01:38, Keith Thompson wrote: >> bart writes: >>> On 16/03/2024 23:19, Keith Thompson wrote: >>>> mitchalsup@aol.com (MitchAlsup1) writes: >>> >>>>> Say you are a programmer and you receive a value like 2^53 from an >>>>> Input read and you wan the most accurate possible SIN( of that ). >>>> I can't think of a scenario where that would be useful (other than >>>> just >>>> doing it for the sake of doing it). >>>> If 2^53 represents a physical quantity, how likely is the actual >>>> value >>>> to be known within ±π (+/i pi for those who prefer ASCII)? >>>> If you can get better precision without too much extra cost, that's >>>> great. I don't know enough to have an opinion about what the best >>>> tradeoff is, but I presume it's going to be different depending on the >>>> application. >>>> Here's a C program that shows how precise sin(2^53) can be for types >>>> float, double, and long double (I used gcc and glibc). The nextafter >>>> functions are used to compute the nearest representable number. For >>>> long double, the value of sin() changes by about 1 part in 1600, which >>>> seems decent, but it's not nearly as precise as for values around 1.0. >>>> For float and double, the imprecision of the argument is enough to make >>>> the result practically meaningless. >>>> >>>> ... >>>> Output: >>>> float (32 bits, 24 mantissa bits) >>>> 9007199254740992.00000000 -0.84892595 >>>> 9007200328482816.00000000 -0.34159181 >>>> double (64 bits, 53 mantissa bits) >>>> 9007199254740992.00000000 -0.84892596 >>>> 9007199254740994.00000000 -0.12729655 >>>> long double (128 bits, 64 mantissa bits) >>>> 9007199254740992.00000000 -0.84892596 >>>> 9007199254740992.00097656 -0.84944168 >> >>> >>> Is this output supposed to be different between gcc -O0 and gcc -O3? >> No, why do you ask? >> On my system, the output is identical with gcc and clang, and tcc at >> all >> optimization levels, with both glibc and musl. I do get slightly >> different results for long double on Cygwin vs. Ubuntu (Cygwin uses >> newlib, not glibc). > > > Because I get the results shown below. Even if the library is > different from yours, I would have assumed matching results. > > > ------------------------------ > > C:\c>gcc c.c -O3 > > C:\c>a > float (32 bits, 24 mantissa bits) > 9007199254740992.00000000 -0.84892595 > 9007200328482816.00000000 -0.34159181 > > double (64 bits, 53 mantissa bits) > 9007199254740992.00000000 -0.84892596 > 9007199254740994.00000000 -0.12729655 > > long double (128 bits, 64 mantissa bits) > 9007199254740992.00000000 -0.84892596 > 9007199254740992.00097656 -0.84944168 > > C:\c>gcc c.c -O0 > > C:\c>a > float (32 bits, 24 mantissa bits) > 9007199254740992.00000000 -0.84893209 > 9007200328482816.00000000 -0.34160271 > > double (64 bits, 53 mantissa bits) > 9007199254740992.00000000 -0.84893209 > 9007199254740994.00000000 -0.12728505 > > long double (128 bits, 64 mantissa bits) > 9007199254740992.00000000 -0.84893209 > 9007199254740992.00097656 -0.84944780 > > C:\c>gcc --version > gcc (tdm64-1) 10.3.0 I see similar results (possibly identical, I haven't checked) with i686-w64-mingw32-gcc on Cygwin. I think it uses the same, or a similar, runtime library as the tdm64 implementation you're using. Comparing the generated assembly, at -O0 it generates a call to "sin", while at -O1 and above it replaces the expression with a compile-time constant. Apparently that compile-time constant matches the run-time computed value for glibc, but not for whatever tdm64 uses. I don't *think* it's a conformance issue as long as the precision is within the standard's (fairly vague) requirements. When I modify the program to start with sin(1.0) rather than sin(2**53), the output is identical at all optimization levels. Apparently glibc and the library used by tgm64 behave differently when computing the sin of very large values. The result for sin(2**53) in long double differs by about one part in 2**17 between -O0 and -O1, or between gcc/glibc and tgm64. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Medtronic void Void(void) { Void(); } /* The recursive call of the void */