History has shown that native code developers concerned with
performance (game devs, graphics devs, etc) will happily use
approximations of these special functions when performance is
important, and will pick approximations with suitable accuracy.

The inverse we have here, where the builtins have unpredictable
precision, requires developers to test on various os/browser
combinations to figure out whether they have precision issues, and if
they do, try to find an accurate high-precision sw implementation of
these builtins and use that. I think this will lead to a lot of
unreliable software out there on the web, and worse, lead to existing
apps breaking when new browser releases reduce precision/accuracy.

If there's a strong desire for high-performance builtin sin, cos, etc
it could be reasonable to add Math.fastCos etc but I feel like most
developers would feel safer with approximations that have known
characteristics, so you should encourage that instead.

On Tue, Jul 29, 2014 at 10:45 PM, Raymond Toy <toy.raymond at gmail.com> wrote:
>
> On Jul 29, 2014 5:47 AM, "alawatthe" <alawatthe at googlemail.com> wrote:
>>
>> Clear rules would also help in discussions like this one:
>> https://code.google.com/p/v8/issues/detail?id=3006
>>
>> Background:
>> V8 implemented a new version of sin and cos, which is faster, but does not
>> have the precision many user want.
>> One of the comments (#8) said about precision:
>>
>> - The ECMA script specification clearly states that Math.sin/cos are
>> implementation-dependent approximations. There is no guarantees required
>> regarding precision.
>>
>> I think, this feels a little bit odd, because where do we draw the line
>> between performance and precision?
>> So, again clear rules (even if they are not as strict as in Java), would
>> help a lot.
>
> Yes. There are no requirements, but the spirit of the spec is clearly to be
> accurate or at least no worse than fdlibm.
>
> Carried to the extreme, this lack of requirements allows implementations to
> be conforming even if all functions returned 0 everywhere. Fortunately, no
> one does that.
>
>>
>> All the best
>> alex aka alawatthe
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

History has shown that native code developers concerned with
performance (game devs, graphics devs, etc) will happily use
approximations of these special functions when performance is
important, and will pick approximations with suitable accuracy.

The inverse we have here, where the builtins have unpredictable
precision, requires developers to test on various os/browser
combinations to figure out whether they have precision issues, and if
they do, try to find an accurate high-precision sw implementation of
these builtins and use that. I think this will lead to a lot of
unreliable software out there on the web, and worse, lead to existing
apps breaking when new browser releases reduce precision/accuracy.

If there's a strong desire for high-performance builtin sin, cos, etc
it could be reasonable to add Math.fastCos etc but I feel like most
developers would feel safer with approximations that have known
characteristics, so you should encourage that instead.