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 <impinball at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140801/f881e45f/attachment.html>

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.