Add tests for IEEE 754-2019 compliance

[kgryte]

Checklist

Please ensure the following tasks are completed before filing a bug report.

• Read and understood the Code of Conduct.
• Searched for existing issues and pull requests.

Description

Description of the issue.

To ensure conformance of @stdlib/math/base/special/* functions with IEEE 754-2019, we should explicitly include compliance tests in the various test suites of the mathematical functions (e.g., pow, exp, etc) present in the standard. The IEEE 754 standard explicitly states behavior for various edge cases for each mathematical function. By including these tests, we can ensure that the underlying implementations, should they change, always remain IEEE 754 compliant.

Related Issues

Does this issue have any related issues?

None.

Questions

Any questions for reviewers?

No.

Other

Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.

No.

[munrocket]

Sinpi/cospi without correct rounding in last ulp.

[kgryte]

@munsocket Can you explain in more detail? How are you arriving at this conclusion? Particularly, how did you determine that sinpi/cospi don't have correct rounding?

[munrocket]

I am just read source code :D

function sinpi(x) {
  return Math.sin(Math.PI*x);
}

Is not enough because floating point numbers perform rounding after each operation(multiplication) in round-to-nearest-even mode.

[kgryte]

That is not our source, which can be found here.

We're not likely to require strict ulp requirements for special functions, as these functions are often affected in subtle ways by upstream deps. For example, simply because sin and cos are accurate to within 1 ulp, this does not mean that a special function consuming them will be accurate to 1 ulp. In fact, slightly less accurate implementations, when consumed by another special function, can result in more accurate results.

IEEE 754 only requires 1 ulp agreement for a small subset of special functions (e.g., sqrt), so we're not likely to enforce such requirements on all special functions.

[munrocket]

Ok, looks legit then :)

[kgryte]

@munsocket Thanks for checking!

[munrocket]

By the way, if your sinpi/cospi will pass compliance tests it is very clever implementation and can be proposed in tc39 and added to javascript specification. Right not I am working on FMA emulation (here snippet), I found it in your 2do list too.

[kgryte]

Yeah, I saw that you are working on fma emulation. :)

Re: TC39. That isn't particularly interesting for us, given that the spec does not require minimum precision requirements. And for good reason: implementations have historically needed the flexibility to trade-off accuracy for increased perf. While libm is the recommended implementation, this is by no means required.

In general, we cannot rely on native JavaScript built-ins to always fulfill accuracy guarantees, and this will remain the case. As such, if a user wants certain guarantees, they'll need to rely on userland implementations, such as those provided by stdlib.