That would also make sense. I do feel that the Math spec should have at least a base requirement. Java requires fdlibm as a baseline, but the correctly rounded requirement would be even better. Definitely a loophole that should've already been closed by now.
Isiah Meadows On Aug 1, 2014 4:14 PM, "Raymond Toy" <[email protected]> wrote: > > > > 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
