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

Subject: Re: [boost] [boostcon][proto] Suggestion for LIAWsession: fixed-pointnumbers
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-03-16 03:12:49

-----Original Message-----
From: boost-bounces_at_[hidden] on behalf of Joel Falcou
Sent: Wed 3/16/2011 2:17 AM
To: boost_at_[hidden]
Subject: Re: [boost] [boostcon][proto] Suggestion for LIAWsession:	fixed-pointnumbers
 
On 16/03/11 05:10, Gruenke, Matt wrote:
>
> > 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.
>
> I think the idea was to use proto to actually look at the whoel 
> expression as a whole and figure out the needed bit storage directly 
> then work within it

In my implementation, the size of the storage used was determined by the template parameters, such that an array of 9.7 fixed-point numbers would only take 2 bytes per element (we actually had such arrays and could not afford for them to be any larger than necessary).  Since each operator was a template where the result was defined in terms of the operands, different unnamed temporaries, within an expression, could use different amounts of storage.  The largest supported storage size was 64-bits, since we were interested in efficiency and required nothing larger.

I have no experience with Boost.Proto.  If the primary purpose of the proposed exercise is as a case study to demonstrate use of Proto, then perhaps my comments are of little or no relevance.  However, if the primary goal is to produce the most useful and efficient fixed-point library possible, then I offer my insights and experience in hopes that a better product might result.

Regards,
Matthew A. Gruenke