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. Carl On Thu, Jul 31, 2014 at 5:16 PM, Isiah Meadows <[email protected]> wrote: > I was looking at the number of complaints about the Math object, > especially regarding the lack of required precision (refer to the thread "Re: > ES6 accuracy of special functions" for a lengthy discussion on this). > Because of this, I propose that a new object, StrictMath, should be added. > This would be analogous to java.lang.Math (performance) vs > java.util.StrictMath (accuracy). People could still define their own > implementations if needed, though. > > Basic specs would be similar to the Math object, but with the following > caveats: > > 1. Fixed-size integer methods such as Math.imul() don't need a StrictMath > variant. > 2. The input precision must be no more than a Float64 in size (depends on > how this is spec'd, may not be necessary). > 3. The output should have an error no greater than 1 ulp (the space > between two adjacent, distinct floating point values, identical to the Java > spec of an ulp). > > I don't see #2 staying if this is spec'd well, but the rest remain. Java's > java.lang.StrictMath actually requires the fdlibm semantics and algorithm > to be used for that class's implementations. java.lang.Math is closer to > this spec in its own specification. > > -- > Isiah Meadows > > _______________________________________________ > 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
