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

Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-03-16 00:10:52

________________________________

From: Ravi [mailto:lists_ravi_at_[hidden]]
Sent: Tue 3/15/2011 11:20 PM
To: boost_at_[hidden]
Cc: Gruenke, Matt
Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers

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

 

I'm not sure we're talking about the same thing, here.  The template parameters of the results returned by my operators were determined by those of the operands.  For instance, 8.16 + 8.8 would return a 9.16.  If the result is then stored into a 16.8, then a right-shift of 8 bits is performed as part of the assignment.  In the case of 0.16 * 8.8, the result is 8.24.

So, the only thing you have to think about is whether you need to force a conversion in the middle of an complex expression to avoid running out of range.  But that can easily be managed by breaking up complex expressions into smaller, simpler ones.

 

> >     * add/subtract return the greater of the int_bits and
> >       frac_bits (independently) of the operands.
> >
> >     * add/subtract returns signedness of the type with the
> >       greater range (choosing unsigned, in the event of a tie).

> Disagreed. Follow the integers - operating on a signed always returns signed.

I don't feel strongly about this point.  I thought it would be sensible to try to follow what C does.

 

> >     * multiply returns a type in which the int and frac bits
> >       are the sum of the corresponding values of the operands.
> >       The result is signed, unless both operands are unsigned.
> >
> >     * The return type of divide is equivalent to multiplying
> >       the numerator by the inverse of the denominator.
> >
> >     * inverse returns a type with one fewer frac bits than the
> >       operand had int bits and one more int bits than the
> >       operand had frac bits.  This sacrifice of precision is
> >       necessary to avoid overflow.
>
> This one is tricky; the behavior you propose is completely unacceptable for
> signal processing.

Which one?  Inverse?  If you need more headroom, you can always add it before the operation (hint: it's free).  I think I included inversion more for completeness.  Is it something you use often?  Since integer division is usually so slow, I expect that most people will just opt for floating point when they get into that territory.

 

Regards,

Matthew A. Gruenke