
Boost : 
Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Neal Becker (ndbecker2_at_[hidden])
Date: 20120411 08:37:37
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?
* 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.
* Most work in signal processing will use 2's complement arithmetic, since it
simplifies hardware implementation in most cases.
* 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.
* fixed point <> flt should be provided. fixed.as_double() for example. Also,
fixed (double, integer_bits, frac_bits) constructor, or something like it.
* 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.
* 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.
* c++11 math functions? You mean trig, etc? No need/desire.
* Performance is very important.
Vicente J. Botet Escriba wrote:
> Hi,
>
> the recent discussion on the MultiplePrecission Arithmetic library has
> show that some people has its ow fixed point library.
>
> Is there an interest in a Boost library having as base
> http://www.openstd.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html?
>
> I have started a prototype
> http://svn.boost.org/svn/boost/sandbox/fixed_point (there is no doc yet
> but the basic goal is quite close to the N3352 C++ proposal). This
> prototype should allow you to play a little bit with.
>
> If yes, what would you like to be changed, added or improved in n3352?
> Next follows some design decisions that IMO need to be decided before hand.
>
> * Should integers and reals be represented by separated classes?
> * Should signed and unsigned be represented by separated classes?
> * Should the library use a specific representation for signed numbers
> (separated sign, 2complement? Let the user choose?
> * Should the library provide arbitrary range and resolution and allocators?
> * Should the library be open to overflow and rounding or just implement
> some of the possible policies? and in this case which ones?
> * Should fixed_point be convertible to/from integer/float/double?
> * Could the result of an arithmetic operation have more range and
> resolution than his arguments?
> * Is there a need for a specific I/O?
> * is there a need for radix other than 2 (binary)?
> * Should the library implement the basic functions, or should it
> imperatively implement the C++11 math functions? Could a first version
> just forward to the c++11 math functions?
> * Should the library support just one of the know ways to name a
> fixedpoint, a U(a,b), nQm, ...? Provide some ways to move from one to
> another?
> * Could expect the same/better performances respect to hand written code?
> * What should be the size used by a fixed_point instance? _fast? _least?
> Should the user be able to decide which approach is better for his needs?
> * Which should be the namespace? boost? boost/fixed_point?
> boost/binary_fixed_point? boost/bfp?
> ...
> * others you can think of.
>
> Please, replay if you are interested, have some experience in the
> domain, good ideas, ..
>
> Best regards,
> Vicente
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk