Subject: Re: [boost] [boostcon][proto] Suggestion for LIAWsession: fixed-pointnumbers
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-04-22 02:32:24
> Message du 22/04/11 02:55
> De : "Gruenke, Matt"
> A : boost_at_[hidden]
> Copie Ã :
> Objet : Re: [boost] [boostcon][proto] Suggestion for LIAWsession: fixed-pointnumbers
> 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 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.
Maybe sometimes, but not always. So I will prefer to been able to state explicitly if I need the smallest builtin representation or the faster one. Up to the implementation to ensure that.
> 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.
I think the result type should be deduced from the parameters type and the operation of course. We need of course to consider when the resulting type can not be represented using the available builtin types.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk