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
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
Le 05/04/12 00:48, Neal Becker a écrit : 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