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

Subject: Re: [boost] [boostcon][proto] Suggestion for LIAWsession: fixed-pointnumbers
From: Ravi (lists_ravi_at_[hidden])
Date: 2011-03-16 12:09:23

On Wednesday 16 March 2011 00:12:49 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.

This is what I have in mind as well. However, Joel's suggestion is also 
interesting, though I would personally consider it an optimization that can be 
performed once the interface is complete.

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

Your comments are very much appreciated. Your experience matches mine quite a 
lot; our (minor) disagreements stem, I think, mostly from my considering a 
larger set of use cases than just speed.

Regards,
Ravi