On Wed, Jul 30, 2014 at 4:31 AM, Katelyn Gadd <kg at luminance.org> wrote:

> 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.
>

​I think Math.fastCos would be difficult to specify. Only the developer
really knows what the appropriate tradeoff between accuracy and speed
should be. Math.fastCos probably won't satisfy that.​


>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140730/be4e0148/attachment.html>

​I think Math.fastCos would be difficult to specify. Only the developer
really knows what the appropriate tradeoff between accuracy and speed
should be. Math.fastCos probably won't satisfy that.