Message du 16/03/11 04:18 De : "Ravi"
A : boost@lists.boost.org Copie à : Objet : Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers
On Tuesday 15 March 2011 18:45:49 Gruenke, Matt wrote:
template< SignProperty is_signed, int int_bits, //!< Number of integer bits. int frac_bits //!< Number of fractional bits.
class CFixed;
I, too, used a class like this in the past, but experience makes me wish for more flexibility. When modeling hardware operations implemented on signal/image processing algorithms, the following schemes have all seen wide use: 1. signed, int_bits, frac_bits <- your design 2. signed, msb_power_of_2, lsb_power_of_2 3. signed, width, int_bits 4. signed, width, frac_bits
Of these, the only one I found to be completely intuitive was the second one. All of the others required non-obvious rules to represent the cases when the MSB is to the right of the binary point or the LSB is much to the left of the binary point. Subsequently, my colleagues and I found that most of the reasoning in choosing appropriate bit-widths is in figuring out the ULP. Our experience led me to propose my design.
I think that this is the format documented on wikipedia http://en.wikipedia.org/wiki/Fixed-point_arithmetic
The way I structured it was to discard information only on assignment (unless the maximum internal storage had overflowed, of course). While I agree that it's tempting to just use int64 for storage, the size and speed implications of creating large arrays of them provides a strong argument against this approach.
Good idea, but this is a refinement that can wait until later.
I don't know if doing as some integer traits could make happy every body. * fast will choose the faster representation * least will choose the minimal representation
Since the most common use of fixed-point arithmetic is for speed, the priority is speed over safety.
In order of decreasing priority: correctness, speed, safety. Safety can be enforced in debug builds.
I agree.
* Converting constructor is implicit, since conversions (such as reductions in precision) are so common, in fixed-point arithmetic.
Agreed, but this is not an issue with the 'assigner' template argument.
I expect however the class will not provide implicit conversions to built-in types. Good luck for those that will participate in the LIAW, Vicente