Improve erf/expm1/expint coverage. #1111
Conversation
In the expm1 case, tighten up error handling and testing.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1111 +/- ##
===========================================
+ Coverage 93.77% 94.36% +0.58%
===========================================
Files 772 774 +2
Lines 61352 59754 -1598
===========================================
- Hits 57535 56386 -1149
+ Misses 3817 3368 -449
... and 8 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Clean up Bessel_ik.
Fixed Conflicts: include/boost/math/special_functions/detail/bessel_ik.hpp include/boost/math/special_functions/detail/bessel_j1.hpp include/boost/math/special_functions/detail/bessel_k0.hpp include/boost/math/special_functions/detail/bessel_k1.hpp include/boost/math/special_functions/detail/igamma_large.hpp include/boost/math/special_functions/detail/lgamma_small.hpp include/boost/math/special_functions/expint.hpp include/boost/math/special_functions/expm1.hpp include/boost/math/special_functions/gamma.hpp include/boost/math/special_functions/log1p.hpp include/boost/math/special_functions/trigamma.hpp test/Jamfile.v2 test/test_expint.cpp
Add support for <cstdfloat> types as well. Extend tests for better coverage.
…svc. Fix mingw linker error.
Disable MP expm1 from coverage check.
In incomplete gamma.
|
@mborland @ckormanyos @NAThompson This PR is now good to go and completes code coverage improvements as far as G for gamma.hpp. There are a lot of accumulated changes here, so I'll hold off for a few days at least in case there are any comments... Also not sure what's happened to the drone CI runner: it seems to be terminally broken right now? |
|
@sdarwin have something gone sideways with our drone config? It looks like we have quite a few runs over the past several days that aren't picking up? There are some like this that seem to have completely crashed before the retry step in the clone phase: https://drone.cpp.al/boostorg/math/2225/193/1 |
There was a problem hiding this comment.
This all looks good to me John. Once it's in I can run it through the actual CUDA testing to see if there's any changes that need to be made there. I think the only thing I saw with the replacement of BOOST_MATH_FP_XXX with the standard FP_XXX macros. No matter since Scipy is now pinned against specific versions instead of tracking develop.
Where was this? I didn't think I'd touched tools/config.hpp? |
| // | ||
| if((boost::math::fpclassify)(prefix) == (int)BOOST_MATH_FP_INFINITE) | ||
| return policies::raise_overflow_error<T>("boost::math::detail::full_igamma_prefix<%1%>(%1%, %1%)", "Result of incomplete gamma function is too large to represent.", pol); | ||
| if((boost::math::fpclassify)(prefix) == (int)FP_INFINITE) |
There was a problem hiding this comment.
| if((boost::math::fpclassify)(prefix) == (int)FP_INFINITE) | |
| if((boost::math::fpclassify)(prefix) == (int)BOOST_MATH_FP_INFINITE) |
There was a problem hiding this comment.
Good catch!
I'll do that before merging.
Unrelated question: should BOOST_MATH_FP_* map to the std values of FP_* ?
There was a problem hiding this comment.
They do: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/config.hpp#L780-L784, except in the case of NVRTC where they map to the conventional values: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/config.hpp#L830-L834, which works since boost::math::fpclassify returns the BOOST_MATH_XXX macro values
In the expm1 case, tighten up error handling and testing.