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.