2014-05-31 13:56 GMT+02:00 John Maddock <jz.maddock@googlemail.com>:

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

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?

I remember when discussing the interface of std::optional on https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposal... people were against having the conversion from U to optional<T> (where U is convertible to T) because it incurred a run-time cost not immediately visible to the guy that used the code: fun(u); // may last longer than you think Instead a more verbose/explicit construct was preferred. Regards, &rzej

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

On May 31, 2014 7:56:00 AM EDT, John Maddock <jz.maddock@googlemail.com> wrote:

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

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 :-(

Apparently the problem isn't as bad as you first thought, but implicitly allocating significant amounts of memory is problematic. You could punt and use the preprocessor to control whether the conversion is explicit. ___ Rob (Sent from my portable computation engine)