On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
> On 10 February 2012 14:05, Andrew Haley <a...@redhat.com> wrote:
>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>>> On 10 February 2012 10:42, Andrew Haley <a...@redhat.com> wrote:
>>>
>>> I think a starting point would be at least documenting correctly the
>>> accuracy of the current libm, because what is currently in the
>>> documents is obviously wrong.
>>> It certainly does not document that sin() is currently more accurate
>>> than sinl() on x86_64 platforms, even with -O0.
>>
>> It isn't.
>>
>> cout << scientific << setprecision(20) << sin(0.5) << "\n";
>> cout << scientific << setprecision(20) << sinl(0.5) << "\n";
>> cout << Sin(Real("0.5")).toString(20,10) << "\n";
>>
>> gives:
>>
>> 4.79425538604203005377e-01
>> 4.79425538604203000282e-01
>> 4.79425538604203000273e-01
>>
>> The last one is from MPFR.
>>
>> In most cases you'll get more accurate results from sinl().
>
> but if you replace 0.5 with 1.0e22 ?
Then it's less accurate. In most cases, however, the long double
version wins. Your statement is not true: in most reasonable cases
sinl() is currently more accurate than sin(), and it does readers of
this list a disservice to suggest otherwise. In the case of absurdly
large arguments it's less accurate, but those cases are less likely to
be significant for real-world computation.
Andrew.
