Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-06-03 12:49:42

>>>> * having an implicit narrowing conversion from double to bigint is a bad idea,

>>>> it should be explicit (it isn't completely obvious from the doc if that is the case).

>>> It's pretty hard to have some constructor conversions implicit and others explicit.
>>> Might be possible with enable_if though.  Will investigate.

>> It's a good comment. You know, a third of the people want it
>> one way, another third want it the other way and the others
>> don't care.

> This is why creating generic libraries is hard. mp_number is a
> generic class that should provide whatever implicit/explicit
> constructor the backend supports. I expect enable_if to allow
> to define such interface. I'm not saying I have a complete solution already.
> In general, I will not provide implicit conversions when there is a
> lost of information. Whether this is a major feature for your library
> is something we can discuss.

<snip>

>> In fact, I believe that Boost.Math already set the bar on this
>> one because when using Boost.Math with an extended precision
>> type (this is possible), all implicit conversions to/from the built-in
>> types are supported.

> I have no experience with Boot.Math, but I suspect that there are
> cases where these implicit conversions are not desired,
> e.g when information is lost.

I understand.

>> I believe it would be incorrect to treat interaction with built-in
>> types behave one way in Boost.Math and a different way in a
>> potential Boost.Multiprecision.
>> 
>> This is my opinion. Others will have different opinions.
>> 

> I suspect that I need to see how Boost.Math works :-)
> Best, Vicente

As far as I know, when you use Boost.Math with any properly
wrapped big-float type, the templates expect seamless interaction
between the wrapped floating-point type and all built-in
data types such as char, short, int, float, double, etc.

Now as far as a potential Boost.Multiprecision is concerned,
I would recommend that whatever Boost.Math needs for
floating-point types should be satisfied by Boost.Multiprecision.

Narrowing conversions of built-in floating-point types and
big integers do not arise in Boost.Math (as far as I know).
And there have been some comments suggesting to
forbid these in Boost.Multiprecision.

I suspect we can sort all of this out in the review.
But my initial feeling is that we have Boost.Multiprecision
in a relatively *boost-compatible* state because we have
thousands of tests already based on Boost.Math.

We will sort this out in review, I hope.

Thanks again, Vicente.
Best regards, Chris.