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-17 02:16:13

-----Original Message-----
From: Ravi [mailto:lists_ravi_at_[hidden]]
Sent: Wed 3/16/2011 12:09 PM
To: boost_at_[hidden]
Cc: Gruenke, Matt
Subject: Re: [boost] [boostcon][proto] Suggestion for  LIAWsession:	fixed-pointnumbers
 
On Wednesday 16 March 2011 00:12:49 Gruenke, Matt wrote:

> > > 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'm not sure I follow.  If he's saying that a single storage size can be determined for evaluating all parts of a compound expression, then I'd expect it to be only the same or larger than what my implementation uses.  The downside of using types that are larger than necessary is that on some architectures divide and sometimes multiply are more expensive for larger operands.

Matt