Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit

Subject: Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-05-31 09:49:29

Le 31/05/14 13:56, John Maddock a écrit :
> Folks,
>
> I have an open bug report 
> https://svn.boost.org/trac/boost/ticket/10082 that requests that 
> conversions from floating point to rational multiprecision-types be 
> made implicit (currently they're explicit).
IMO, any conversion that loss information must be explicit. Only one 
conversion that doesn't loss information could be implicit.
I guess that there is no implicit conversion from rational 
multiprecision-types to floating point.

Does the floating point to rational multiprecision-types really don't 
loss information, i.e. does the following hold?

double d1 = 0.1;
rational_mp r1 = d1;
double d2 = double(r1);
rational_mp r2 = d2;
assert(r1==r2);

Vicente
>
> Now on the one hand the bug report is correct: these are non-lossy 
> conversions, so there's no harm in them being implicit.  However, it 
> still sort of feels wrong to me, the only arguments against I can come 
> up with are:
>
> 1) An implicit conversion lets you assign values such as 0.1 to a 
> rational (which actually leads to 3602879701896397/36028797018963968 
> not 1/10), where as making the conversion explicit at least forces you 
> to use a cast (or an explicit construction).
> 2) Floating point values can result in arbitrarily large integer parts 
> to the rational, effectively running the machine out of memory. 
> Arguably the converting constructor should guard against that, though 
> frankly exactly how is less clear :-(
>
> Does anyone else have any strong views or insights into this?
>
> Thanks in advance, John.
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>