Re: [boost] [multiprecision] Design question on variable precision types.

Subject: Re: [boost] [multiprecision] Design question on variable precision types.
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-08-22 18:56:52

AMDG

On 08/22/2018 12:28 PM, John Maddock via Boost wrote:
> I have a tricky design question that Boost.Multiprecision has been
> dodging relating to variable precision types - these have just expanded
> somewhat now that we support complex numbers via mpc as well as mpfr's
> reals etc.
> 
> The basic use case is this:
> 
> We have a set of numbers at very high precision, some calculations are
> performed on those directly, others we want to temporarily drop
> precision, get an approximate answer and perhaps later refine it. 
> Generally speaking, performance trumps everything, on a really long
> running calculation 10-20% speedup can actually make a big difference
> (in $$'s in some cases if the CPU time is from the cloud).
> 
> Up till now Boost.Multiprecision has been dodging this issue - it's
> actually pretty hard to program in a sane and consistent way, so the
> message has been "don't mix precisions" when using a type like
> boost::multiprecision::mpfr_float - just set what default you want and
> get on with it.  But we really should do better than that.
> 
> So... with the help of Danielle Brake I've been trying to nail this down
> in develop, what we have at present is:
> 
> <snip>
> 

How about something like this:
- Assignment always preserves the precision of the source.
- Mixed precision arithmetic uses the maximum precision of
  any argument.
- There is an explicit function for setting the precision.
- There is an way to force assignment to use the precision
  of the destination, but it must be explicit in some way.

I believe these are the correct semantics, without
regard for performance.  So, to get performance back:
- When using expression templates and the precision of the
  result is set, the precision of intermediate results
  may be reduced as long as it does not change the final
  result too much.  (The definition of "too much" is
  left as an exercise for the reader).

In Christ,
Steven Watanabe