S390x testing

[jzmaddock]

No description provided.

[jzmaddock]

OK folks, this PR has fixed very nearly all the 128-bit long double related issues, nearly all so far have been testing-related rather than library related which is good. @mborland , @NAThompson I wonder if I can draw your attention to the following last few failures, even hints on where to start looking would be useful:

whittaker_shannon_test has a very large number of errors of the order 10^-25 which is 7162055944ULP which seems to be too large to ignore. In logs at https://drone.cpp.al/boostorg/math/1080/27/2

daubechies_scaling_test has errors of the order of 10^8ULP but only with 19 vanishing moments? See log https://drone.cpp.al/boostorg/math/1080/27/2

test_autodiff_2 and test_autodiff_3 have error rates that suggest truncation to double somewhere, but I simply don't know where to start looking: https://drone.cpp.al/boostorg/math/1080/38/2

Thanks!

[jzmaddock]

OK in daubechies_scaling_test here:

math/test/daubechies_scaling_test.cpp

Line 291 in 346d2a9

std::array<long double, 6> lin_3{0.0L, 1.638452340884085725014976L, -2.232758190463137395017742L,

we have test data with insufficient precision. Is this possible to obtain at higher precision or is it from the paper? If the latter then I'll just disable testing that at 128-bit long double precision.

[mborland]

OK folks, this PR has fixed very nearly all the 128-bit long double related issues, nearly all so far have been testing-related rather than library related which is good. @mborland , @NAThompson I wonder if I can draw your attention to the following last few failures, even hints on where to start looking would be useful:

whittaker_shannon_test has a very large number of errors of the order 10^-25 which is 7162055944ULP which seems to be too large to ignore. In logs at https://drone.cpp.al/boostorg/math/1080/27/2

daubechies_scaling_test has errors of the order of 10^8ULP but only with 19 vanishing moments? See log https://drone.cpp.al/boostorg/math/1080/27/2

test_autodiff_2 and test_autodiff_3 have error rates that suggest truncation to double somewhere, but I simply don't know where to start looking: https://drone.cpp.al/boostorg/math/1080/38/2

Thanks!

Nothing stands out to me as to why these have such high error. @pulver may be able to speak more intelligently to autodiff.

[pulver]

test_autodiff_2 and test_autodiff_3 have error rates that suggest truncation to double somewhere, but I simply don't know where to start looking: https://drone.cpp.al/boostorg/math/1080/38/2

@pulver may be able to speak more intelligently to autodiff.

The 28 autodiff errors can be classified into 4 subsets that should have straight-forward fixes:

1. test_autodiff_2.cpp(334): error: in "test_autodiff_2/ylogx<__float128>": The expected relative error is around 1.9e-32% but the actual appears to be around 3.3e-32%. In this case simply increasing eps from a factor of 100 to 300 to be safe should work.
2. exceeds 1.92593e-32% test_autodiff_2.cpp(541): error: in "test_autodiff_2/atan2_function<__float128>": 25 of the 28 errors occur on this line. It looks like it is due to simply missing using boost::math::atan2; so that the std version was being called instead. (Assuming boost provides a 128-bit version of this function.) Similarly for the 2 errors below. For example the acosh() test is correctly written as it allows for proper ADL to occur.
3. test_autodiff_3.cpp(19): error: in "test_autodiff_3/atanh_test<__float128>": Missing using boost::math::atanh;.
4. test_autodiff_3.cpp(53): error: in "test_autodiff_3/erf_test<__float128>": Missing using boost::math::erf;.

[mborland]

The autodiff tests are all green now; only interpolators remains.

[jzmaddock]

Whew, this is all green now. @mborland @NAThompson any reason not to go ahead and squash and merge? Any pending PR's likely to conflict with this?

[mborland]

I have no issues with this being merged.

[jzmaddock]

OK good, merged.