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.
>

​Note that, as mentioned in the ES6 accuracy of special functions thread,
java.lang.Math actually specifies accuracy requirements. This differs from
Javascript where there are no requirements.

Math should specify some accuracy requirements and since the spec
specifically mentions fdlibm, the accuracy of fdlibm should be the minimum
requirement.

As for the StrictMath, I would go one step further and say StrictMath must
produce correctly rounded results for the special functions. This might
have been unrealistic a few years ago, but take a look at crlibm
<http://lipforge.ens-lyon.fr/www/crlibm/> that implements the C99 special
functions that are correctly rounded (and provably correct) and is also
fairly efficient. One nice side effect of requiring correctly rounded
results is that the spec doesn't have to specify the algorithm.  There is
one and only one correct answer, and implementors are free to do whatever
they want to achieve it.

And finally, if there is to be a package with sloppy accuracy requirements
(or lack there of), it should not be named Math. Call it FastMath or
SloppyMath or whatever as long as it's not Math.  "Math" has certain
connotations and sloppiness is not one of them. However, I feel that
without some kind of spec, its utility is greatly diminished because every
implementation will be sloppy to a different degree.

Also as mentioned in the ES6 accuracy thread, the people who need
sloppiness know what kind of sloppiness they can tolerate and will do their
own, ignoring any FastMath library.

>
> --
> 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/20140731/161182e7/attachment.html>

​Note that, as mentioned in the ES6 accuracy of special functions thread,
java.lang.Math actually specifies accuracy requirements. This differs from
Javascript where there are no requirements.

Math should specify some accuracy requirements and since the spec
specifically mentions fdlibm, the accuracy of fdlibm should be the minimum
requirement.

As for the StrictMath, I would go one step further and say StrictMath must
produce correctly rounded results for the special functions. This might
have been unrealistic a few years ago, but take a look at crlibm
<http://lipforge.ens-lyon.fr/www/crlibm/> that implements the C99 special

functions that are correctly rounded (and provably correct) and is also
fairly efficient. One nice side effect of requiring correctly rounded
results is that the spec doesn't have to specify the algorithm.  There is
one and only one correct answer, and implementors are free to do whatever
they want to achieve it.

And finally, if there is to be a package with sloppy accuracy requirements
(or lack there of), it should not be named Math. Call it FastMath or
SloppyMath or whatever as long as it's not Math.  "Math" has certain
connotations and sloppiness is not one of them. However, I feel that
without some kind of spec, its utility is greatly diminished because every
implementation will be sloppy to a different degree.

Also as mentioned in the ES6 accuracy thread, the people who need
sloppiness know what kind of sloppiness they can tolerate and will do their
own, ignoring any FastMath library.