I have experimented with the quadmath library included with gcc and the boost::math::constants library and encountered several problems.
- typeid is seemingly not supported for __float128, which requires an overload of nameof<__float128> - the stream extraction operator has to be provided for __float128 for string conversion to work - a specialisation of numeric_limits has to be provided.
Is there an interest in incorporating __float128 into boost ? If so, would it be a good idea to specialise constants for __float128 as well, apart from float, double and long double?
Funnilly enough I wondered about this the other day, but haven't had the time to do anything about it. Plus I've rather been hoping that the GCC guys would make __int128 and __float128 first class citizens and render the issue moot ;-)
Well, finally IEE754:2008 has a full specification of quadruple-precision floating-point types. It will probably, however, take a long time for these to be widely supported by compiler vendors.
An open question is whether we should add a "binding" header under boost/math/bindings or whether it would be better to wrap __float128 and libquadmath as a multiprecision type under boost/multiprecision.
The latter option has the advantage that we don't have to pollute the global namespace with std lib overloads for __float128.
Of course a simpler solution is possible if you just want the numeric constants working for __float128, but it would be nice to make the type a first class C++ type that interoperates with all of Boost.Math. John.
If you would like my opinion, I would recommend creating a backend for boost::multiprecision::number, as John has suggested. The backend *looks* formidable in code, but it is quite lightweight. This would provide a very nice resource for Boost. When I published the original work that partly influenced boost::multiprecision, I did a similar wrapping of the Fortran77 type REAL*16. Yes, you heard right, Fortran77! This kind of wrapped type is very efficient because the underlying type is a native one, as would be expected as well for a wrap of GCC's __float128. But John, don't you already have the wrap? During the review of Multiprecision, you provided evidence of the lightweight overhead of boost::multiprecision::number by implementing a wrap for the native double type. I seem to remember that you implemented this wrap as a template for potentially any native type. Would this potentially be another project for GSoC 2013? Sincerely, Chris.