Re: assigning a "float128" variable with a regular "double" variable

From: Jacques Mequin (j-mequin_at_[hidden])
Date: 2021-11-27 08:56:06

Thanks,

This was a stupid Boost beginner question

Boost is great

After calculating, with Maxima, the symbolic equations of some
analog circuits, I am doing numeric simulations based on
recursive convolution involving for example exponentiation of
matrices or inversions

Depending on components values the "long double" are sometime
not enough

Regards,
  Jacques

________________________________
De : Boost-users <boost-users-bounces_at_[hidden]> de la part de John Maddock via Boost-users <boost-users_at_[hidden]>
Envoyé : vendredi 26 novembre 2021 20:20
À : Jacques Mequin via Boost-users <boost-users_at_[hidden]>
Cc : John Maddock <jz.maddock_at_[hidden]>
Objet : Re: [Boost-users] assigning a "float128" variable with a regular "double" variable

On 26/11/2021 17:50, Jacques Mequin via Boost-users wrote:
>
> I am a fresh new user   ( I need to extend some EIGEN library feature
> by using your float128 )
>
> How to assign a "float128" variable with a regular "double" variable ?
>
> With my source code in attachement
>
>       double       double_pi =  3.141592653589793     ;
>       float128  float128_pi =  3.141592653589793Q  ;
>
>       produces the output that looks fine to me
>
>       double_pi =
>       3.141592653589793e+00
>
>       float128_pi =
>       3.141592653589793000000000000000000e+00
>
> but  thestatement    float128_pi = double_pi ;    produces
>
>       float128_pi =
> 3.141592653589793115997963468544185e+00
>
> How to get 3.141592653589793000000000000000000e+00 also from an
> assigment  ???

You can't: remember your double has 53-bit precision, 3.141592653589793
is it's decimal value ROUNDED to 16 decimal places (note that you would
have to print more digits than that to be able to round-trip to and from
decimal), converting to a float128_t gives you EXACTLY the same binary
value, but you're code is now printing out more decimal places, so
you're seeing it's "true" decimal value, rather than the rounded value
you had before from the double output.

Hope that makes sense, John.