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
>>> 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
>> 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
>> 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.
> 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
c = a+b;
will do what is expected for fp<2,5>+fp<2,5> -> fp<2,5> (taking in
If the conversion between different fixed points is explicit we need to cast
c = fp<2,5>(a+b);
The other FPGA design needs
c = a+b;
The single problem is that this design doesn't prevent you for using
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk