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.open-std.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, 2-complement? 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 fixed-point, 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