Math standalone

[mborland]

Offer better context detection of Boost.Math standalone in conjunction with Boost.MP standalone.

[mborland]

@jzmaddock Almost all of my failures are in the concepts test where fpclassify/isnan/isinf are replaced with a macro that is designed to generate a compilation failure (example). Is there a workaround for this or something I am missing? I am just calling the boost::math implementation for almost all of these (see new <boost/multiprecision/detail/fpclassify.hpp>)

[jzmaddock]

Although they're declining in number, there are some platforms that define isnan/isinf etc as macros (rather like the min/max issue on Windows), so all those functions need to be macro expansion proof.

For declarations we can do that with:

bool isnan BOOST_PREVENT_MACRO_SUBSTITUTION(T args); // or
bool isnan /*Suppress macro expansion*/(T args);

For calls it's either:

(boost::math::isnan)(x) // or
boost::math::isnan  BOOST_PREVENT_MACRO_SUBSTITUTION(x); // or
boost::math::isnan /*Suppress macro expansion*/(x);

HTH, John.

[jzmaddock]

Hi Matt, thanks for persevering with this, I think we can simply things here quite a bit, but I need to check through the changes line by line to be sure, so be prepared for a small blizzard of line-comments!

[jzmaddock]

OK, apologies for the comment blizzard, but I think we can simplify things a lot with this.

Note that in general, I'd rather not replace calls to boost::math::isnan to std::isnan as the former keeps working even when certain "fast-and-loose" optimisations are in place. One option to reduce the #if logic, would be a macro that expands to either using std::isnan or using boost::math::isnan depending on which is available.

[mborland]

I think this latest commit simplifies what you were looking for. It defines macros such as BOOST_MP_ISINF that either expands to boost::math::isinf if it is available, or SFINAEd definitions of isinf depending on if the type is supported by existing definitions (e.g. STL and libquadmath)

[jzmaddock]

Thanks Matt, can we just get rid of the floor/ceil code in place of std::floor/ceil, and then hopefully this should be good to go?

[mborland]

Thanks Matt, can we just get rid of the floor/ceil code in place of std::floor/ceil, and then hopefully this should be good to go?

Locally I don't see any issues with std::floor/ceil so the superfluous code is gone now. Sorry I missed that one with the fixes earlier.

[mborland]

@jzmaddock This should be good now. The 2 failures are timeouts on the CI's side.

[mborland]

Upon a deeper look this is in fact not good to go. I spun up a VM that has nothing installed to see where we are at. There are more lingering instances that need to be removed/replaced.

[mborland]

@jzmaddock This is now good to go. I pulled this branch into a VM with none of boost installed and it all compiles now.

[mariospr]

FWIW, and just in case it helps: I was initially not being able to build this multiprecision library in standalone mode off the develop branch because of several references to <boost/math/...> not guarded by the BOOST_MP_STANDALONE define, when I tried to do it yesterday for the first time before finding this PR.

But then I found this PR and I can confirm I could build in standalone mode now with the only addition of Boost.Config, which I had to download as well as it's still referenced from standalone_config.hpp (despite of the comment saying that this package "already includes a copy of Boost.Config so no other donwloads are required", which I must say confused me a bit).

Anyway, this is not a review (I'm not qualified at all to do so), just a quick comment based on my recent experience in case it helps in some way. Thanks a lot for this PR in any case!.

[mborland]

@mariospr I am glad to hear that this PR works for you. The intent is to have a packaged standalone release on the home page much like we do with Boost.Math that will include Boost.Config. The updates to the docs may have been pre-mature so I apologize for the confusion.

[mariospr]

@mariospr I am glad to hear that this PR works for you. The intent is to have a packaged standalone release on the home page much like we do with Boost.Math that will include Boost.Config.

Ah, I see, that makes a lot of sense, thanks for clarifying.

The updates to the docs may have been pre-mature so I apologize for the confusion.

No worries. I'm not too familiar with Boost so I was unsure after reading the README whether I was missing something out, but this explains things, thanks again.

[mborland]

Ping @jzmaddock. We are coming up on the beta/release window, and I think it's important this makes it.