Re: [boost] [Boost.FixedPoint] Choose notation

Subject: Re: [boost] [Boost.FixedPoint] Choose notation
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-04-29 07:02:21

On Apr 29, 2013, at 3:26 AM, Michael Marcin <mike.marcin_at_[hidden]> wrote:

> On 4/29/2013 1:46 AM, Andrey Semashev wrote:
>> On Mon, Apr 29, 2013 at 10:41 AM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>> 
>>> In my prototype I used
>>> 
>>> fxp_uint and fxp_int
>>> fxp_ufract and fxp_fract
>>> (fxp_ufreal and fxp_real)
>>> 
>>> Now if you put these classes on a specific namespace for each notation the
>>> choice of the default can be deferred without a major impact on the plan.
>>> 
>>> namespace fixed_point {
>>>   namespace q { }
>>> 
>>>   namespace cxx1y {}
>>>   // if the default is cxx1y notation (a better name is welcome, e.g. rr
>>> for range and resolution)
>>>   using cxx1y::fxp_uint;
>>>   using cxx1y::fxp_int;
>>>   ...
>>> }
>>> 
>>> fxp::q::fract<8,4>;
>>> fxp::rr::uinteger<8,4>;
>> Please, no cryptic abbreviations (and especially one letter names).

+1

> I've always felt that if floating point numbers are called float then fixed point numbers should be called fixed.
> 
> fixed<24,8> representing a signed 24.8 fixed-point would be my preferred naming convention.

+1

> It could be an alias for signed_fixed<24,8> much like int is for signed int. Then naturally if you needed to support unsigned fixed point types you could use unsigned_fixed<24,8>.

ufixed is another possibility, since "u" is a common prefix for "unsigned."

> I could see an argument made for fixed<int32_t,4> specifying the storage type and the radix, in this case 28.4. This handles the signed vs unsigned naturally and doesn't allow you to have (in my view) strange types like 8.4 which seems to require an odd 12bit integer type.

+1

> If you absolutely needed an 8.4 type then you need fixed-width integer support beyond that provided by <cstdint>. You could provide an implementation of integer<12> that is a 12 bit integer and then make fixed<integer<12>,4>. In my opinion this is another library outside the scope of a fixed-point library.

Is such a fixed point type truly necessary? I can imagine cases of wanting to pack a wire or file format as tightly as possible, but what data type would really benefit from such range and precision?

It doesn't seem as if this proposal addresses an important use case for fixed point: currency. If the exponent is binary, then it doesn't provide exact fractions for currency, for which tenths, hundredths, and thousandths are important, but sixteenths, for example, are not. Did miss something?

___
Rob

(Sent from my portable computation engine)