On Fri, Aug 1, 2014 at 11:40 AM, Brendan Eich <[email protected]> wrote:
> Mathias Bynens wrote: > >> 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. >> > > Right, we are not going to add StrictMath. > > The notes from this week's TC39 meeting at Microsoft will be published > soon, some time next week, but to cut to the chase: we agreed to specify > harder and stop the benchmarketing race to the bottom, as Carl suggested. > We will need f.p. gurus helping review the work, for sure. Thanks to all of > you contributing here. > This is really great news! > > /be > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
