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

Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers
From: Gruenke, Matt (mgruenke_at_[hidden])
Date: 2011-03-16 22:24:31

-----Original Message-----
From: Ravi [mailto:lists_ravi_at_[hidden]]
Sent: Wed 3/16/2011 2:21 AM
To: boost_at_[hidden]
Cc: Gruenke, Matt
Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-pointnumbers
 
On Tuesday 15 March 2011 21:10:52 Gruenke, Matt wrote:
> > > All of the others required non-obvious rules to represent the cases when
> > > the MSB is to the right of the binary point or the LSB is much to the
> > > left of the binary point.
> >  
> > 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.
>
> In the system you proposed, what are the template parameters for the fixed-
> point number with the following range?
>  { 0, 1, ..., 15 } x 2^{-11}

11 fractional bits.

> Or, the fixed-point number holding values in the following range?
>  { 0, 1, ..., 15 } x 2^{11}

15 integer bits.

> Fixed-point numbers are used in plenty of places where speed is not an issue

I've used them to represent timestamps, for instance.  The combination of range, precision, ease of computation, and associative addition were all desirable properties.

> firmware in embedded control systems with no floating point unit is another. 
> In such cases, falling back to floating-point is not an option.

Software floating-point libraries are sometimes an option.  Especially when IEEE-754 compliance isn't required.

Anyway, getting back to inversion, I just figured that overflowing is a nasty scenario to allow.  I guess the better thing to do is keep all the precision and just expand the integral portion of the result by 1 bit.  If the total number of bits is too large, then perhaps the user can tweak the operand, use an alternate function, or go the manual route.

Matt