Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers

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 
> 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