This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: sparc, ia64: Compute cos(M_PI_2l) for your 128-bit long double please.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, David Miller <davem at davemloft dot net>, vapier at gentoo dot org, brooks_moses at mentor dot com, libc-alpha at sourceware dot org, joseph at codesourcery dot com, aj at suse dot com, thomas at codesourcery dot com
- Date: Thu, 11 Apr 2013 10:15:50 -0400
- Subject: Re: sparc, ia64: Compute cos(M_PI_2l) for your 128-bit long double please.
- References: <5164D25B dot 9090406 at redhat dot com> <m2fvyyjp82 dot fsf at igel dot home> <5165CFDE dot 6020709 at redhat dot com> <20130410 dot 233850 dot 1096713545971361798 dot davem at davemloft dot net> <20130411123902 dot GF20323 at brightrain dot aerifal dot cx> <mvm7gk9xllk dot fsf at hawking dot suse dot de> <20130411130943 dot GG20323 at brightrain dot aerifal dot cx> <5166BCC5 dot 4000301 at redhat dot com>
On Thu, Apr 11, 2013 at 09:38:13AM -0400, Carlos O'Donell wrote:
> On 04/11/2013 09:09 AM, Rich Felker wrote:
> > On Thu, Apr 11, 2013 at 03:06:47PM +0200, Andreas Schwab wrote:
> >> Rich Felker <dalias@aerifal.cx> writes:
> >>
> >>> I would just use something like "%.100000g\n".
> >>
> >> If you use %g you need at most DECIMAL_DIG digits.
> >
> > No, that's wrong. DECIMAL_DIG is sufficient if you want to round-trip
> > the value back. But here we want to print the exact value in order to
> > use an external tool to apply cos() to that value.
>
> I assume that it's sufficient to use as many digits
> as M_El or M_PI_2l actually have once converted to
> the type in question?
>
> For example for float/double/long double on x86-64
> M_El converts as:
> 2.7182817459106445312500000000000000000000000000000000000000000000000000000000000000000000000000000000e+00
> 2.7182818284590450907955982984276488423347473144531250000000000000000000000000000000000000000000000000e+00
> 2.7182818284590452354281681079939403389289509505033493041992187500000000000000000000000000000000000000e+00
x86_64 has ld80, which only needs 64 decimal places. For IEEE quad,
you need more than 100 places. This is basic arithmetic; every time
you divide by 2, you need an extra decimal place to represent the
result.
> Which to me indicates that %.100 was sufficient to
> export this value for use in the external tool.
If it works, it's by chance, or at least I can't find any rigorous
explanation of why it should work. The error will be much less than
1ulp relative to the input, and the smoothness of cos translates that
to roughly the same absolute error in the output, but the output is so
small that this could be a huge error relative to the size of the
output.
Rich