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.
>> 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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk