Use C++17 function ellint_1 in adams.cpp #4388
Conversation
Replace approximate series for F(x, 1/sqrt(2)) by a call to ellint_1. The approximate series was only accurate to "better than 1e-7", which meant that the errors in the projection were typically about 1 m. The adoption of ellint_1 (with its considerably better accuracy) then leads to a torrent of errors in the tests. These have been fixed by changing the tolerances from 1 mm to 1 m. The values in the tests should be replaced by more accurate ones, but I'm reluctant merely to update the values with the ones the code now produces given that the code depends on a parameter TOL = 1e-9. Also, I don't understand why K(1/sqrt(2)) = std::comp_ellint_1(RSQRT2) = 1.8540746773013719 is sometimes given to only 5 decimal places as 1.85407.
|
it seems clang 18.1.8 both on MacOS with Conda and OSSFuzz Linux lacks support for std::ellint_1() which feels weird (the failure on AppVeyor is likely due to it using MSVC17. we should probably retire that configuration) |
|
This is non-essential PR. I was just seeing how C++17 provides. I close this for now and we can revisit this in a year or so. |
that's a bit strange as my reading of https://en.cppreference.com/w/cpp/numeric/special_functions/ellint_1 is that it should be a mandatory feature of a C++17 compliant environment (there are some parts sometimes of the C++ standards that are optional). Wondering if there aren't mixup of compilers and header of standard library from older compiler, or something like that |
Replace approximate series for F(x, 1/sqrt(2)) by a call to ellint_1.
The approximate series was only accurate to "better than 1e-7", which meant that the errors in the projection were typically about 1 m. The adoption of ellint_1 (with its considerably better accuracy) then leads to a torrent of errors in the tests. These have been fixed by changing the tolerances from 1 mm to 1 m.
The values in the tests should be replaced by more accurate ones, but I'm reluctant merely to update the values with the ones the code now produces given that the code depends on a parameter TOL = 1e-9. Also, I don't understand why K(1/sqrt(2)) = std::comp_ellint_1(RSQRT2) = 1.8540746773013719 is sometimes given to only 5 decimal places as 1.85407.