Re: Radians Or Degrees?

On 17/03/2024 03:57, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 17/03/2024 01:38, Keith Thompson wrote:

bart <bc@freeuk.com> 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.
 

That is interesting.  It might not be a conformance issue, but it is a divergence from the intention of the compiler.  gcc makes use of a very comprehensive library that emulates a whole range of floating point hardware implementations to try to get bit-perfect compile-time versions of run-time calculations, precisely so that it can do compile-time calculations that fully match what you would get at run-time, regardless of compilation flags and optimisation.
So if the program is producing different results for run-time and compile-time versions of "sin", then there is a mismatch between the configuration of the compiler and the run-time library it is using.  I don't know enough about the configuration options for gcc (there are a /lot/ of them), but I know it can be configured to assume you are using glibc or a glibc-compatible library.  Perhaps the mingw build here is configured with this option, but is actually using a run-time library with a slightly implementation of these functions (such as an MS DLL C library).  If that is the case, then this is a mistake in the configuration of gcc here, and I would think it could be reported back to the mingw people as a bug.