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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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 09:38:13 -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>
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
Which to me indicates that %.100 was sufficient to
export this value for use in the external tool.
Cheers,
Carlos.