Sujet : Re: Radians Or Degrees?
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.lang.c comp.archDate : 17. Mar 2024, 10:34:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240317113458.00000021@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
On Sun, 17 Mar 2024 11:06:21 +0200
Michael S <
already5chosen@yahoo.com> wrote:
On Sat, 16 Mar 2024 16:19:11 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
mitchalsup@aol.com (MitchAlsup1) writes:
Michael S wrote:
On Sat, 16 Mar 2024 01:16:25 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
Keith Thompson wrote:
I can see how computing sin(x) with high precision for
"reasonable" values of x would be useful, but does any of that
benefit from being able to compute sin(2^53) accurately?
Because accurate argument reduction reduces the burden on the
programmer to remain within his sandbox.
Not really.
>
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.
<snip>
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.
To make the point more clear I'd rather change it to following form:
<snip>
BTW, personally I'd prefer to illustrate futility of Payne-Hanek or
equivalent reduction with following example:
#include <math.h>
#include <stdio.h>
#include <limits.h>
#include <float.h>
void foo(long double x)
{
const double y = (double)sinl(x);
printf("%.20Le %25.16La %.17f\n", x, x, y);
}
int main(void) {
const float a0 = 0x1p56;
const float b0 = 11;
{
printf("%-12s (%3zu bits, %d mantissa bits) ",
"float", CHAR_BIT * sizeof (float), FLT_MANT_DIG);
const float a = a0;
const float b = b0;
const float x = a / b;
foo(x);
}
{
printf("%-12s (%3zu bits, %d mantissa bits) ",
"double", CHAR_BIT * sizeof (double), DBL_MANT_DIG);
const double a = a0;
const double b = b0;
const double x = a / b;
foo(x);
}
{
printf("%-12s (%3zu bits, %d mantissa bits) ",
"long double", CHAR_BIT * sizeof (long double), LDBL_MANT_DIG);
const long double a = a0;
const long double b = b0;
const long double x = a / b;
foo(x);
}
}