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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-11 18:11:04

Le 11/04/12 23:03, Christopher Kormanyos a écrit :
> <snip>
>
> First up, one might want to consider some top-level requirements.
> - How might fixed-point fit with an extended complex class?
Yes, I need this also, but I don't see any major issue. Do you?
> - If Boost.Multiprecision or a multiprecision type is ever
> specified, how might fixed-point fit with it.
The goals are different, so I think different libraries are needed. One 
can question if interaction is needed.
> - If a multiprecision integer type ever gets specified, should
> the representation of fixed-point be allowed to use it for
> mantissa and decimal parts?
I don't see any problem on using it as underlying representation. My 
prototype has as parameter the underlying type, so this should be 
possible. Of course, I'm not saying it works now ;-)
>
>> * Should integers and reals be represented by separated classes?
> I don't see the need for integers in the first place.
I'm wondering if the library will be simpler as the operations are not 
the same. If we have only one class, enable_if should be used to make 
the difference.
>
>
>> * Should signed and unsigned be represented by separated classes?
> Yes, in my opinion.
I agree also, even if my prototype use only one class.
>
>> * 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.
I think that when a single word is enough to represent the fixed-point 
2's complement is the bets choice. When more than a word is needed, 
having the sing on all the word is a lost of space, and as you say 
whether it is represented represented by left-most word/limb or as a 
separated data should be an internal decision. In this case using more 
space seems IMO to be a minor issue.
>
>> * 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.
I agree, performances must be preserved for small fixed-points (in width).
>
>> * 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?
No, I don't think not-a-fixed-point is something desirable.

Implementing a close design could open some optimizations that the open 
design could forbids ;-) But some one said already that premature 
optimization is root of all evil, isn't it? Other said KISS.
>
>> * Should fixed_point be convertible to/from integer/float/double?
> Yes, absolutely, in my opinion.
Implicit or explicit conversion?
>
>> * 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.
have you any requirements?
>
>> * 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).
I prefer also to concentrate on Radix-2 and let Radis-10 for another 
library.
>
>> * 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.
I hope others share your opinion here.
>
>> * 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.
I don't have access to this kind of processors. I will contact you once 
I have confidence with the performances on general purpose processors.
>
>> * 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.
Ye, but which one? the faster, the smaller or let the user choose?

> 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).
I don't know if I forgot this question. Could the first version of the 
library be limited to only one builtin underlying representation?
>
>> * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp?
> For me, boost/fixed_point
+1.
And the name classes?
>
>> 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.
>
Thanks for your detailed comments, suggestions and opinion. That will 
help me a lot.

Best,
Vicente