@Brendan that's great! (I sent my message early by accident) Isiah Meadows On Aug 2, 2014 4:31 PM, "Isiah Meadows" <[email protected]> wrote:
> 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
