jzmaddock
jzmaddock
>Could we get your opinion? We have code that uses fixed-width 2's complement bit vectors, where the width is determined at runtime but doesn't change over the lifetime of an...
I agree the top level release notes are incorrect here - we decided some time ago on the ML that libraries could drop C++03 support, and that means dropping compilers...
> and multi-precision fails on all of those: As expected, we no longer support pre-c++11 compilers. > More generally, this is exactly why I argued (at length) that the decision...
I dimly remember fixing a clash between optional and multiprecision.... here's one anyway: https://github.com/boostorg/multiprecision/pull/95, I'm fairly sure there was another somewhere - basically both had some under-constrained enable_if's which could...
I can reproduce @thebrandre 's issue locally with msvc-14.2, the problem is basically that Boost.Build uses a different pdb name for each .obj that it builds - this includes when...
> Actually, that is the fix https://github.com/boostorg/multiprecision/pull/543 that will require C++17, in Boost 1.82. If anyone can figure out a way to make this operator https://github.com/boostorg/multiprecision/blob/02e753d60364d2318827a98f7b12d98cc60244a4/include/boost/multiprecision/detail/number_base.hpp#L960 work in C++11 (or...
I think it's the other way around: there is only one true infinity representation, but there are multiple NaN's possible: https://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_negative_infinity >BTW do the binary integer representations of nan and...
>But the behaviour of float_next and float_prior is entirely within the choice of Boost.Math author? Haha, yes :)
Thats interesting! Does it pass the tests?
OK, but as pointed out in the article, your trick fails when the two inputs differ in sign (this includes when one input is zero). I also get a negative...