* Expand the document of Catmull-Rom spline
It is not clear from the current documentation how the curve parameter is relates to how to interpolate between any two of the input points, which is, at the end of the day, one reason for using spline interpolation. Here a blurb is added to the doc, following https://github.com/boostorg/math/issues/211.
* Remove unneeded newline in catmull_rom doc
This adds some extra instrumentation to bessel_j0.hpp, everything else are fixes for the test programs.
The advantage of testing on this platform is that it has a true 128-bit long double which is a good test of our assumptions in code.
When switching the default long double format on ppc64le to ieee128, this test
does not compile as nanq is not available. In such cases nanl should be used
instead.
Also, calling nanl with argument 0 raises warnings as it expects a char*. Change
the argument to an empty string, which keeps the purpose of the test and avoids
new warnings.
Include an "escape macro" so thread safety can be disabled if certain bernoulli features are to be used in a no-atomics environment.
Fixes https://github.com/boostorg/math/issues/673.
* Fix comment typos: "endinaness" to "endianness"
* Change the C++20 checks (for both `__cplusplus` and `_MSVC_LANG`)
to be strict: `> 202000L` to `>= 202002L`
* Add an `#error` when C++20 `<bit>` is missing, just in case.
* Fix the `_WIN32` definitions. All Windows platforms are little-endian
(regardless of x86/x64/ARM/ARM64), `<boost/predef/other/endian.h>`
correctly reports little-endian, and MSVC's STL simply hardcodes
`enum class endian { little = 0, big = 1, native = little };`, see
f75c7f596c/stl/inc/bit (L271) .
* Add a `static_assert` to verify that exactly one of
`BOOST_MATH_ENDIAN_BIG_BYTE` or `BOOST_MATH_ENDIAN_LITTLE_BYTE` is
true. This avoids the need for "Endian type could not be identified"
consistency checks below.
* Fixboostorg/math#677 by not testing `BOOST_MATH_ENDIAN_BIG_BYTE` and
`BOOST_MATH_ENDIAN_LITTLE_BYTE` with the preprocessor, as
`std::endian::native` isn't a preprocessor constant. Now, this simply
expects `BOOST_MATH_ENDIAN_BIG_BYTE` to be usable in a constant
expression, and assumes (due to the consistency check above)
that if we aren't big-endian, we must be little-endian.
