[Strawman proposal] StrictMath variant of Math
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 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.
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
- math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html
- 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!
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.
@Brendan that's great! (I sent my message early by accident)
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:
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.