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. > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
