
Boost : 
Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 20120411 17:03:25
<snip>
First up, one might want to consider some toplevel requirements.
 How might fixedpoint fit with an extended complex class?
 If Boost.Multiprecision or a multiprecision type is ever
specified, how might fixedpoint fit with it.
 If a multiprecision integer type ever gets specified, should
the representation of fixedpoint be allowed to use it for
mantissa and decimal parts?
> * Should integers and reals be represented by separated classes?
I don't see the need for integers in the first place.
> * Should signed and unsigned be represented by separated classes?
Yes, in my opinion.
> * Should the library use a specific representation for signed numbers (separated sign, 2complement? Let the user choose?
Very good question. A separate bool flag for sign slows down the library and increases
storage requirements. The sign of the leftmost limb could be the sign. But this
breaks down for allfractional types. I guess, perhaps, the separate sign information
might be a necessity. But I'm not sure.
> * Should the library provide arbitrary range and resolution and allocators?
Unfortunately, the allocator seems necessary for high digit counts.
But perhaps a hybrid container with compiletime width for low limbcount
and allocation for a (specifiable, zero allowed) higher limb count could be used here.
But be sure to make fixedpoint fast for low digit counts, possibly
using template specialization when the fixedpoint can be represented
by a builtin integer type (in assiciation with "get my int type" compiletime helper templates).
This is what I have done in the past. Low digit counts is the key range for fixed.
> * Should the library be open to overflow and rounding or just implement some of the possible policies? and in this case which ones?
Where do you start, where do you stop?
This is like the sign bit. Do you want extra information
for the subnormals or use some magic values?
> * Should fixed_point be convertible to/from integer/float/double?
Yes, absolutely, in my opinion.
> * Could the result of an arithmetic operation have more range and resolution than his arguments?
No. But copy construction and copy assign maybe, whereby the LHS
dictates the digit count.
> * Is there a need for a specific I/O?
Yes.
> * is there a need for radix other than 2 (binary)?
Coming from a guy who has written *a lot* of specialized number classes...
I have always been haunted by radix10. Never again for me. Radix2
and don't look back (my opinion).
> * 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?
It should fit in with Boost.Multiprecision, if there ever is such a thing.
Users like me who need a tiny set of trig functions for, say, an
8bit controller can rolltheirown via template specialization.
Don't even get started with cordic, Chebyshev, polynomial expansion,
Pade, Taylor, NewtonRaphson, FFT multiplication, AGM, etc., etc., etc. and the rest.
Just make the numbers! We will be happy for that because it's really a lot.
C++ should have the templated math functions and an extended complex type
elsewhere. You just need to make the number types.
> * 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?
It's implementationdependent. But if your 7.8 and 15.16 signed splits are
slower than singleprecision float on an 8bit core, you will get flack for it.
> * 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?
It's implementation defined. For small digit counts, I would try to fit it in
a builtin type. For medium digit counts, a fixed, optionally fixedhybrid container
of std::uint_fast32_t. For very high counts, use an established fast integer
representation with its own fastmultiply (like a potential Boost.Multiprecision).
> * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp?
For me, boost/fixed_point
> it seems that there is no interest or perhaps people are too busy on on vacations
Sorry for the late response in this detail.
I was really busy. Thank you.
Best regards, Chris.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk