Re: [boost] [fixed_point] Request for interest in a binary fixed point library

Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-11 11:26:10

Le 11/04/12 14:37, Neal Becker a écrit :
> I'm afraid I don't understand n3352 (and don't have a lot of time to study it
> now).  I don't understand why there are 4 different types.  I would expect fixed
> point to have at most 2 types: signed and unsigned.  I see no point in
> distinguishing integral and fractional types: the integral type is just setting
> the binary point to 0?
You are right. I guess that the integral types are there to make evident 
that the operations applicable to these types are different.
>
> * signed and unsigned must both be supported.  Whether that is done via 2
> different classes is a design issue.  There does have to be some way to support
> mixed arithmetic between them, but explicit conversion is OK.
The problem appears even if we define a single class with a template 
parameter for the sign, as the classes will be different types and the 
class need to take care of mixed arithmetic.
>
> * Most work in signal processing will use 2's complement arithmetic, since it
> simplifies hardware implementation in most cases.
I'm used to work with 2's complement also.
>
> * It is OK if maximum size is set by some base integer size.  Fixed point means,
> use some underlying base integral type for internal representation (and
> arithmetic), but interpret the binary point in the appropriate position.  This
> base integral type should probably be a template parameter.
My prototype use the underlying type to manage the size and the sign at 
once. n3352 uses two classes and has no constraint on the used 
underlying type type other than it must be large enough, with the 
possibility to uses several chunks.
>
> * fixed point<->  flt should be provided.  fixed.as_double() for example.
Should the

fixed point ->  flt conversion take care of the rounding policy?

> Also,
> fixed (double, integer_bits, frac_bits) constructor, or something like it.
Could you be more precise, please?
>
> * I don't need/want automatic conversion of widths with arithmetic operations.
> I'm not even sure if this can be done in a way that is always correct.
Well I guess we can do it correctly;-)
>
> * No need for any special I/O, other than some way to pretty print the result.
> For I/O, and for serialization, it is sufficient to make the required internal
> members accessible.
I  understand that providing access to the underlying type open possible 
extensions, but the internals would be quite complex when managing 
chunks of words. Should the library be limited to builtin underlying 
types without chunks?
>
> * c++11 math functions?  You mean trig, etc?  No need/desire.

>
> * Performance is very important.
>
>
Thanks for your comments,
Vicente