Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-04-21 18:02:45
> Message du 16/03/11 04:18
> De : "Ravi"
> A : boost_at_[hidden]
> 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
> 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.
> > * 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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk