
Boost : 
Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixedpointnumbers
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 20110421 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: fixedpointnumbers
>
> 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 nonobvious 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 bitwidths 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/Fixedpoint_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 fixedpoint 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 fixedpoint
> > arithmetic.
>
> Agreed, but this is not an issue with the 'assigner' template argument.
I expect however the class will not provide implicit conversions to builtin types.
Good luck for those that will participate in the LIAW,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk