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: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-11 17:03:25

<snip>

First up, one might want to consider some top-level requirements.
- How might fixed-point fit with an extended complex class?
- If Boost.Multiprecision or a multiprecision type is ever
specified, how might fixed-point fit with it.
- If a multiprecision integer type ever gets specified, should
the representation of fixed-point 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, 2-complement? 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 left-most limb could be the sign. But this
breaks down for all-fractional 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 compile-time width for low limb-count
and allocation for a (specifiable, zero allowed) higher limb count could be used here.
But be sure to make fixed-point fast for low digit counts, possibly
using template specialization when the fixed-point can be represented
by a built-in integer type (in assiciation with "get my int type" compile-time 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 sub-normals 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 radix-10. Never again for me. Radix-2
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
8-bit controller can roll-their-own via template specialization.
Don't even get started with cordic, Chebyshev, polynomial expansion,
Pade, Taylor, Newton-Raphson, 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 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?
It's implementation-dependent. But if your 7.8 and 15.16 signed splits are
slower than single-precision float on an 8-bit 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 built-in type. For medium digit counts, a fixed, optionally fixed-hybrid container
of std::uint_fast32_t. For very high counts, use an established fast integer
representation with its own fast-multiply (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.