jzmaddock

>Your example does not satisfy the preconditions. Well.. that's why I gave it as an example, if we exclude the special cases of roots that touch but do not cross...

You are correct that we should not be promoting to an emulated type, that's just silly. Changing to not promoting double on x86 systems has been on my list of...

We have an expected error rate for the "largest real type", and all the other real's are then assumed to be zero error. The largest real depends on the compiler/platform,...

>EDIT: Scratch the comment about BOOST_CHECK_CLOSE, it might be just a confusing print, mixing absolute and relative difference... Not quite... it's a really bad design fault in the now rather...

I would need to double check, but I seem to remember fixing this while doing some code-coverage work. Ah, yes it is, see: https://github.com/boostorg/math/blob/develop/include/boost/math/special_functions/detail/bessel_ik.hpp

My bad, you are correct that this is NOT fixed in develop, but IS in this branch/PR: https://github.com/boostorg/math/pull/1111 that is still at least somewhat work in progress. I would prefer...

Apologies @StephanTLavavej, since I haven't merged the other branch, lets just go ahead and merge this one, and I'll deal with the conflicts later.

> The numerical integrators already work this way. For example the tanh-sinh integrator gets all the nodes/weights created in the constructor, and then many integrands can be integrated using the...

Hi @grafikrobot and thanks for this, two quick questions: 1) Why the extra dependencies libs/static_assert libs/throw_exception libs/preprocessor when we really shouldn't have any pretty much. 2) I see project requirements...

Merged from parallel PR.