Yes! Absolutely interested!
I use fixed-point extensively with hard real-time microcontroller systems. I am particularly interested in stuff like a 7.8 and 15.16 signed split.
What 7.8 stands for? 7 bits for the integer part and 8 for the fractional part? I use 7.8, for example, for a signed 16-bit type with one sign bit, seven mantissa binary digits and eight binary fractional digits.
I guess you prefer a specific class for signed fixed_points and not a template parameter. sfp<7,8> versus fp<int16_t, 7,8>
Do you mind if the library propose some meta-function to specify different formats, e.g. format_i_f<7,8>::type and format_i_f<15,16>::type An alternative design is to have a format parameter, so for example the user could use specific formats
where i_f has as parameters the number of integral and fractional bits and r_r has as parameters the range and resolution. Currently my prototype and the C++ proposal uses this r_r format. Others use the total number of bits (width including the sign) and the fractional w_f I can use anything. The great advantage of your selected convention is that it is absolutely clear how many digits
<snip> there are in mantissa and fraction. I like it.
Do you mind if the rounding strategy is a template parameter? An enumeration or and open policy? Do we even really need a rounding policy? I honestly don't know. I thought the whole deal with fixed-point was to free us from the burdens of formal floating-point representation and obtain efficiency and exactness via near-integer representation. Maybe others have a clear, or more formal, suggestion here.
Do you have any preferences for the namespace and class names? Yes, in other post, "boost/fixed_point".
Any comment is welcome. I'll try on the weekend.
Best regards, Chris.