On Sun, 1 Jun 2025, Yuao Ma wrote:
> For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less accurate implementations.
> I've also added tests to ensure everything works as expected.
I don't see tests for the various special cases from Annex F (for example,
"tanpi(n) returns +0, for positive even and negative odd integers n." and
"tanpi(n) returns −0, for positive odd and negative even integers n.").
In such cases the sign of zero would need to be checked specifically (via
copysign or signbit).
> +static int
> +mpfr_cospi (mpfr_ptr rop, mpfr_srcptr op, mpfr_rnd_t rnd)
> +{
> + mpfr_t cs, n, r, two;
> + int s;
> +
> + mpfr_inits2 (2 * mpfr_get_prec (op), cs, n, r, two, NULL);
Such a choice of precision should come with comments to justify why it's
sufficient for whatever accuracy you claim this implementations achieves.
In the case of cospi, for example, if an argument is close to 0.5 then
multiplying by pi before computing the cosine loses a lot of precision
(compared to computing a value close to 0, multiplying by pi and computing
the sine); is this extra precision intended to make up for that? And does
GCC always use the same precision for the result as for the input (MPFR
itself does not require that)?
Similar considerations may apply to other functions as well - and would be
avoided by not trying to do the optimizations with older MPFR versions.
--
Joseph S. Myers
josmy...@redhat.com
