Subject: Re: [boost] [boostcon][proto] Suggestion for LIAWsession: fixed-pointnumbers
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-04-21 20:44:28
On Thu 4/21/2011 6:02 PM, Vicente BOTET wrote:
> > 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:
> I think that this is the format documented on wikipedia http://en.wikipedia.org/wiki/Fixed-point_arithmetic
The point of confusion was that his implementation was general enough to handle numbers where the value of the lsb > 1. I agree that this generalization has sufficient value to warrant use of a different template parameter scheme. I think something like <sign, log2(msb), log2(lsb)> is pretty sensible and implementation-friendly.
> > > 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
In most cases, smaller WILL be the faster implementation. Where this is not the case, the compiler can hopefully help out and provide most of the benefits of hand-tuning for a particular architecture.
I think the difference between Ravi's proposal and mine is really down to something I don't consider an implementation detail. When I implemented fixed-point templates, I parameterized the return type of operators, in order to avoid discarding any information. The only place where I discarded information was on assignment/conversion. It's not just about loss of information, but actually the semantics of the operators.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk