On 1 Aug 2014, at 09:25, Carl Shapiro <carl.shapiro at gmail.com> 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.

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