On 1 Aug 2014, at 09:25, Carl Shapiro <[email protected]> wrote:
> Thanks for the suggestion. > > As Ray pointed out, the Math package in Java still has its accuracy > requirements specified and so it is not analogous to the current status of > Math package in ES6. Also, the StrictMath package and the strictfp class > qualifier came about in Java back when the x87 was the predominant FPU. > Because of the idiosyncrasies of the x87 one could not compute bit-identical > floating point results without additional overhead. Nevertheless, the > accuracy requirements and conformance was still achieved with satisfactory > performance. Much of the history is still available on-line > > http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html > http://math.nist.gov/javanumerics/reports/jgfnwg-02.html > > It is unclear how much of these "strict" modes is still relevant given that > SSE2 is now the predominant FPU. The strict modes were always effectively a > non-issue on other architectures. > > Much of the pressure to relax the accuracy of the special functions seems to > be coming from their use in various benchmark suites and the tireless efforts > of the compiler engineers to squeeze out additional performance gains. > Requiring bounds on the accuracy of the special functions has the additional > benefit of putting all the browsers on equal ground so nobody has to have > their product suffer the indignity of a benchmark loss because they try to do > the right thing in the name of numerical accuracy. +1 Introducing a new global `Math` variant wouldn’t solve the interoperability issues. IMHO, the accuracy of the existing `Math` methods and properties should be codified in the spec instead. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
