Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at