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.
fixed point -> flt conversion take care of the rounding policy?
> 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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk