Le 11/04/12 23:21, Christopher Kormanyos a écrit :
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 see so, it corresponds to the i_f format.
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 <snip> 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 there are in mantissa and fraction. I like it. I will try introducing the format as a parameter on my prototype soon.
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.
Converting from fixed_point numbers with different resolution needs rounding. Divide request also a resolution to which round. Best, Vicente