Re: [boost] [fixed-pt] (was [Review Request] Multiprecision Arithmetic Library)

Subject: Re: [boost] [fixed-pt] (was [Review Request] Multiprecision Arithmetic Library)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-05 12:12:02

Le 05/04/12 00:48, Neal Becker a écrit :
> Vicente J. Botet Escriba wrote:
>
>> Le 04/04/12 13:17, Neal Becker a écrit :
>>> Here is my current run-time fixed-pt.  In this version, fixed-pt bit widths
>>> are
>>> set at run-time, becuase I use this from python.  It is simple to convert
>>> this to compile-time if desired.
>>>
>>> The code is based on the boost::constrained_value
>>>
>>> http://pastebin.com/tXkeGAMf
>>>
>> Hi,
>>
>> I have no doubt of the utility of a fixed point library with constraints
>> given at run-time, but I will prefer that the interface be based on
>> Range and Resolution (as in
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.htm)
>> instead of in IntegerBits and FractionalBits.
>>
>> I need sometimes to have fixed points that have less bits than
>> fractional bits and give negative numbers for IntegerBits or
>> FractionalBits seems to me counterintuitive. Of course this is just a
>> point of view and conversion between the different formats could be
>> provided by the library.
>>
>> Best,
>> Vicente
>>
> 1. It's easy to convert to compile-time constraints.  Actually, this code was
> compile-time, and I converted to run-time.
>
> 2. I use this code for modelling fixed point hardware design (FPGA).  In that
> case, we must be very explicit about the bit widths of every operation, and
> every temporary result.
I understand why in your case it could be better to don't adapt 
automatically the result type to the arguments and you need to master 
the result type. Maybe on your FPGA design fp<2,5>+fp<2,5> -> fp<2,5> 
but other can design it as <2,5>+<2,5> -> <3,5>.

Note also that the automatic promotion don't force you to use 
temporaries so

fp<2,5> a,b,c;
c = a+b;

will do what is expected for fp<2,5>+fp<2,5> -> fp<2,5> (taking in 
account overflow).

If the conversion between different fixed points is explicit we need to cast

c = fp<2,5>(a+b);

The other FPGA design needs

fp<2,5> a,b;
fp<3,5> c;
c = a+b;

The single problem is that this design doesn't prevent you for using 
temporaries.

> One reason I prefer not to have any automatic
> promotion.  Also because, only in simple cases can the compiler guess the
> correct sizes needed for results, so it's better for the user to be forced
> to be explicit.
>
>
I agree that the result deduction can not be done in general and that 
each algorithm becomes specific for the input /output quantizations and 
every time you change the input /output quantizations you need to review 
the internal quantization. This is one of the major drawbacks of 
fixed-point algorithms. What I don't see is how your design improves 
this. Could you give an example?

Best,
Vicente