Boost logo

Boost :

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-05-31 16:10:54

Thank you for your comments, Vicente. >> I have spent some hours reading the documentation. Here are some comments and a lot of questions. Did you get a chance to use it also? You always have such good comments, that we would benefit from some your experience with use-cases. >> * As all the classes are at the multi-precision namespace, >> why name the main class mp_number and not just number? >> typedef mp::number<mp::mpfr_float_backend<300> > my_float; > Good question :) > I don't have a particulary strong view whether it's "number" or > "mp_number", but would like to know what others think. I actually *do* have a slight preference for "mp_number", with the *mp_* part. It simply reminds me that I'm actually doing something with multiple precision type. An experienced booster once told me that boost favors clarity over terseness. Perhaps this is a case thereof. >> * I think that the fact that operands of different backends can not >> be mixed on the same operation limits some interesting operations: I understand your comment, Vicente. In my experience, the reduced error resulting from forbidding non-explicit mixing of back-ends far outweighs potential benefits from allowing them. Of course, this is only an opinion. Others will disagree. When we discussed potential fixed-point types, you may remember my recommendation. I usually recommend: * Do support seamless interaction with built-in types. * Forbid implicit conversion of non-same specialized types. * Potentially support explicit construction of one type from another. Accordingly, we do support this: boost::multiprecision::cpp_dec_float_100 a(boost::multiprecision::cpp_dec_float_100(123) / 100); boost::multiprecision::cpp_dec_float_50  b(boost::multiprecision::cpp_dec_float_50(456) / 100); boost::multiprecision::cpp_dec_float_50 c = boost::multiprecision::cpp_dec_float_50(a) * b; But we do not support this: boost::multiprecision::cpp_dec_float_100 a(boost::multiprecision::cpp_dec_float_100(123) / 100); boost::multiprecision::cpp_dec_float_50  b(boost::multiprecision::cpp_dec_float_50(456) / 100); boost::multiprecision::cpp_dec_float_50 c = a * b; >> * What about replacing the second bool template parameter by an enum class expression_template {disabled, enabled}; which will be more explicit. That is > Not a bad idea actually, I'd like to know what others think. I like the suggestion. >> * can we convert from a cpp_dec_float_100 to a cpp_dec_float_50? >> if yes, which rounding policy is applied? >> Do you plan to let the user configure the rounding policy? > Yes you can convert, and the rounding is currently poorly defined :-( > I'll let Chris answer about rounding policies, but basically it's a whole lot of work. > The aim is not to try and compete with say MPFR, but be "good enough" > for most purposes.  For some suitable definition of "good enough" obviously ;-) Yes, I confirm John's statement. You can explicitly convert. Unfortunately, there simply is no support for rounding at this time in the cpp_dec_float back-end. To be quite honest, I do not have the time to work out a sensible rounding scheme for the base-10 back-end in a reasonable time schedule. One of the difficulties of base-10 is its unruly nature regarding rounding. I see the present review candidate of Boost.Multiprecision as a good start on a long-term development with many potential future improvements. In particular, my long-term goal with a potential Boost.Multiprecision is to create a greatly improved base-2 floating-point back-end in the future. At that time, I would want to target vastly improved performance, sensible allocation/deallocation, clear rounding semantics, etc. One of the advantages of John's architecture is that mp_number can be used with any back-end fulfilling the requirements. So one could potentially phase out cpp_dec_float via deprecation in the future and support a future cpp_bin_float. >> If not, what about a mp_number_cast function taking as >> parameter a rounding policy? > I think it would be very hard to a coherant set of rounding policies > that were applicable to all backends... including third party ones > that haven't been thought of yet. Basically ducking that issue at present :-( Yes, and keep ducking. We won't get it done correctly in a reasonable time scale. In my opinion, we can consider in association with an improved BPL base-2 floating-point back-end in the future. Backwards compatibility could be achieved with a potential rounding policy of *no rounding*. MPFR, GMP, MPIR and the rest will get the rounding that they have or don't have. >> * Do you plan to add constexpr and noexcept to the interface? >> After thinking a little bit I'm wondering if this is this possible >> when using 3pp libraries backends that don't provide them? > I'm also not sure if it's possible, or even what we would gain - I can't > offhand think of any interfaces that could use constexp for example. If you are aiming at compile-time constant mp_numbers, then I do not believe it is possible with the specified low-complexity constraints a constexpr functions and objects. This works with state-of-the-art compilers today.   constexpr double pi = 3.14159265358979323846 But this may not work soon, or ever.   constexpr boost::multiprecision::cpp_dec_float_50 pi("3.14159265358979323846264338327950288419716939937510582097494"); >> * Why the "Non-member standard library function support" >> can be used only with floating-point Backend types? >> Why not with fixed-point types? > Because we don't currently have any to test this with. I performed some rudimentary tests with Boost.Multiprecision and my own fixed-point type for microcontrollers. The results were preliminarily positive and I do see potential here. I am greatly looking forward to progress with fixed-point. >> * How the performances of mp_number<this_trivial_adaptor<float>, false> >> will compare with float? > No idea, might be interesting to find out, will investigate. I never tested it yet. It interests me as well for my research in generic numeric programming. Thank you for your detailed comments and suggestions. Best regards, Chris.

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