tc39
enforce some minimum accuracy bound for implementation-approximated values
It appears there is a web compatibility dependency on some level of accuracy of implementation-approximated results of Math functions. See https://github.com/compat-table/compat-table/issues/392 and https://github.com/es-shims/es6-shim/commit/90c803f68390dd13fd5297b1e2d54d44f8dac94b for a research starting point.
We should figure out just how accurate these values are expected to be and try to document that within ECMA-262.
https://github.com/tc39/notes/blob/ee2ea8abd37d68a9dff17d50461d07ba68ef979c/meetings/2015-05/may-27.md?plain=1#L403-L422 as well.
Additional history: This issue also surfaced in 2014. TC39 discussed it in person here and here. At the time, there seemed to be general agreement that math functions should be within at most 1 ulp, however no spec change proposal was advanced at the time.
There was some follow-up discussion about whether an ulp bound is enough, as there were reports of applications also depending on various symmetries and invariants, such as:
sin(x) == -sin(-x)
sin(x) <= 1
sin(x) >= -1
cos(x) == cos(-x)
cos(x) <= 1
cos(x) >= -1
Collecting all such invariants for all Math functions that applications might be depending on might be challenging, but in a recent conversation @michaelficarra pointed out to me that incrementally specifying invariants as they're discovered to be needed would be better than not specifying anything at all.
After the 2015 discussion there was also some follow-up investigation of whether crlibm might enable TC39 to require fully correct rounding for more things, however at that time it wasn't practical. Today, CORE-MATH, RLIBM, and LLVM libc might make this more practical.
There are a bunch of existing libraries that compute exact, correctly rounded results for the trig and exponential functions. A lot of these are offshoots of crlibm. Here's one, used by the European Space Agency.
