Claas wrote:
I have experimented with the quadmath library included with gcc and the boost::math::constants library
and encountered several problems.
Paul wrote:
But meanwhile, have you considered using the cpp_dec_float (and cpp_int) types from Boost.Multiprecision. A predefined 50 digit version is very easy to use, and a 40 digit version almost as easy.
Claas wrote:
Actually I already wrote my own overload of numeric_limits, io-operators, math functions and std::complex. Thus things work relatively smooth for me.
I just figured, that probably many users meanwhile created the same overloads, so I wondered if there is a critical mass to supply this code in boost to avoid a lot of duplicate code generation.
We hear you. In fact, you are really preaching to the choir on this one. We have all done numerous workarounds, waiting patches and re-writes of Fortran stuff, all to get our hands on the 34 digits of quad. Claas wrote:
I agree, that this should best be provided by the compiler people, but since libquadmath is around for quite a while and no C++ support is available yet, I needed an intermediate solution.
You are right again. I know how frustrating this is! Claas wrote:
The thing with boost constants is, that it does not provide explicit support for __float128, so constants are generated from strings. Thus I was wondering if there are plans to provide constexpr overloads similar to the built-in types for __float128. As far as I can tell, the number of digits in the stored (non-string) constants is sufficient, so replacing "L" by "Q" in the long double specialisations should do the trick (plus adding the new type of course).
This is where we need to reach a decision. GCC's __float128 is an exotic, non-standard type. Nonetheless, it is popular and widely used. If we decide to support it in Boost, the right place is probably not in the constants section of Boost.Math, but rather as a backend type for Boost.Multiprecision, as mentioned earlier by John. In this way you would retain near-native performance and attain access to *all* the functions in Boost.Math, including the constants. In addition, there is a Boost extended complex library waiting for a review manager. So if we ever get complex reviewed and potentially into Boost, then you will be able to use types other than float, double and long double with complex. Of course, you are a rough-and-ready programmer and you already wrote your own --- like everyone else who needs it has to do (frown). The frustrating thing is that it will take us a long time to add support for the functions you need. It will, however, probably take compiler vendors longer to support quad. So in the intermediate time, you still need to roll your own quadmath, complex for quad, numeric limits for quad, etc. But you might seriously consider writing your own backend for Boost.Multiprecision using __float128. If you do this and use Boost.Multiprecision consistently as a template parameter in your generic math algorithms, then you can also use, via template parameter, the multiprecision types mentioned by Paul if the 34 digits of quad are insufficient and you need the 50 or 100 or more digits of Boost.Multiprecision. If we can get a consensus on support for GCC's libquadmath in Boost.Multiprecision, I would volunteer to write the backend for it. But I need a few months before I get that kind of time slot for writing, testing, etc. I wonder what John and Paul think about adding support for this. I'm skeptical because the type really only works with one compiler, and then you need to --enable-quadmath when building GCC in order to get it. It's a nightmare! Good luck and please keep in touch if you would like to pursue this matter further. Sincerely, Chris.