On 10 February 2012 14:36, Andrew Haley <a...@redhat.com> wrote:
> 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.
>
I was trying to make the point that the accuracy varies depending on
input values, and this fact should be documented.
I.e. Accurate to 1 ulp for x in the range of ...
Not just "sin(x) is accurate to 1 ulp"
You say "In most reasonable cases sinl() is currently more accurate than sin()".
I am suggesting that we specify the range of x considered to be reasonable.
The term "reasonable" seems to me to be inexact.
