Re: [boost] [fixed_point] Request for interest in a binary fixed point library

Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-11 17:19:59

Le 11/04/12 20:23, Phil Endecott a écrit :
> Hi Vicente,
>
> Vicente J. Botet Escriba wrote:
>> the recent discussion on the MultiplePrecission Arithmetic library 
>> has show that some people has its ow fixed point library.
>
> You might like to review old discussions of fixed point, e.g.:
>
>    http://thread.gmane.org/gmane.comp.lib.boost.devel/157744
>    http://thread.gmane.org/gmane.comp.lib.boost.devel/158019
>    http://thread.gmane.org/gmane.comp.lib.boost.devel/178257
>
> and several other threads.
Thanks for pointing to these threads. I will read them carefully.
>
>> Is there an interest in a Boost library having as base
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?
>
> Thanks for pointing out that doc which I'd not seen before.  I've not 
> yet read it properly.
>
> FWIW, my view is that:
>
> - Some people conflate fixed point with features like saturation, 
> which I would prefer to decouple.  Fixed-point arithmetic without 
> saturation is useful, as is integer arithmetic with saturation.  So 
> I'd prefer to make them orthogonal, but compatible, concepts.
Would the overflow::ignore policy responds to your needs?
>
> - There are difficult decisions to make about the result types of 
> arithmetic operations, analogous to this:
>
>   int32_t a, b;
>   int64_t c;
>   c = a+b;  // oops.
>
> It is tempting to make the return type of e.g. operator+ large enough 
> to accommodate the largest possible sum, and to truncate only when the 
> assignment occurs.  But I think this will have an unavoidable runtime 
> overhead. 
Are you referring to the fact that a and b must be promoted before? or 
that the operation is done on the promoted type? Or maybe both?

The promotion is not really needed always. For example

fp<int64_t,32,0> a,b;
fp<int64_t,33,0> c;
c=a+b;

No promotion needed in this case, but the operation is done on int64_t.

> Some will argue that expression templates can be used to work around 
> this, but that dramatically increases the complexity of the library.
>
An alternative is to define functions that have the result type as 
template parameter, so if what you want is
fp<int32_t,32,0> a,b;
fp<int32_t,32,0> c;
c=a+b;

you use instead

c = plus<fp<int32_t,32,0>>(a,b);

here plus could be optimized and don't promote to fp<int64_t,33,0>. I 
have not implemented this yet, but I expect this to be as efficient as 
if we did

   int32_t a, b;
   int32_t c;
   c = a+b;

in the case overflow is ignored. Of course, and implementation should be 
needed to probe the expectations.

> - There are also difficult decisions to make about implicit and 
> explicit conversions.
Are you referring to the conversion between fixed-point types with 
different rand or resolution? Yes, this is a conflicting point and has a 
deep impact on the design of the library. I don't know if we can manage 
by providing both.

My prototype as well as the C++ proposal allows implicit conversions 
when there is no loss of data and requires some kind of fixed point cast 
if information could be loss.

   {
     unsigned_number<2,-3> n1((index(1)));
     unsigned_number<2,-2,round::negative> n2;
     n2=number_cast<unsigned_number<2,-2,round::negative> >(n1);
   }

An explicit convert function could also be used to avoid repeating the 
target type

     convert_to(n1, n2);

>
>
> These are some of the same questions that you asked in your post.  
> Different people will have different requirements.  It is perhaps 
> because of this that everyone tends to "roll their own", and no 
> standard implementation has emerged.
You are surely right and perhaps we can not provide something that 
satisfy all the requirements. This was the main reason of my post, to 
know the expectations of the Boost community. I hope however that we can 
have a Boost library that solves some of the major issues, whether the 
library could be used as a base for standardization is something that we 
could discuss later, if a library emerge and is accepted in Boost.

Thanks again,
Vicente