Boost logo

Boost :

Subject: Re: [boost] [math] Support for libquadmath/ __float128
From: Claas H. Köhler (claas.koehler_at_[hidden])
Date: 2013-02-22 10:28:56


On 22/02/13 13:33, Paul A. Bristow wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Claas
>> Sent: Thursday, February 21, 2013 3:24 PM
>> To: boost_at_[hidden]
>> Subject: [boost] [math] Support for libquadmath/ __float128
>>
>> 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?
>
> As John and Chris have observed already, it would be nicest to have proper compiler and platform
> support for __float128, including numeric_limits, and/or full.
>
> I'm not sure how to facilitate this but perhaps firstly users need to do more asking?
Where should I best complain? :-)

> 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.

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.

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.

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).

On the other hand, this would probably require the additional
functionality of <math>, <complex> and numeric_limits to be consistent.

>
> Of course, speed will not be nearly as good, but accuracy will be fine.
>
> Paul
>
>
> ---
> Paul A. Bristow,
> Prizet Farmhouse, Kendal LA8 8AB UK
> +44 1539 561830 07714330204
> pbristow_at_[hidden]
>
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk