Re: [boost] GSOC 2013 fixed_point

Subject: Re: [boost] GSOC 2013 fixed_point
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-23 18:24:28

Le 20/04/13 06:14, Michael Marcin a écrit :
> On 4/19/2013 7:15 PM, Vicente J. Botet Escriba wrote:
>> Le 18/04/13 15:39, Dmitriy Gorbel a écrit :
>>> I want to provide my proposal to the Boost community.
>>>
>>> Please, lets discuss it! I will be grateful for your reviews and 
>>> advices.
>>> How can I improve it?
>>> I appreciate any feedback you may have.
>>>
>>> proposal_Dmitriy_Gorbel.pdf
>>> <http://boost.2283326.n4.nabble.com/file/n4645577/proposal_Dmitriy_Gorbel.pdf> 
>>>
>>>
>>
>> <snip very good feedback>
>>
>
> There is a typo: The range must be *grater* then the resolution
>
> I don't understand your types.
>
> cardinal<16> 0 <= n <= 65536
>
> This seems to be a 16 bit unsigned type but requires 17 bits to store 
> this range. It should probably be 0 <= n <= 65535.
>
> integral<4> -16 <= n <= 16
>
> Similar here this seem to be a 5 it signed integer but requires 6 bits 
> to store this range. It should probably be -16 <= n <= 15.

The intention of Laurence was to be able to return the same type while 
applying the unary minus operator.

With your range the result of -integral<4> is integral<5> or the 
operation needs to check for overflow, which is not good neither.
Using an additional bit allows to overcome this deficiency but of course 
lost a possible value out of the 2^n. Of course this would needs 
consensus on this ML.
> nonnegative<8,-4> -256 < n < 256 in increments of 2^-4 = 1/16
>
> I don't understand how a type nonnegative can store values in (-256,0).
>
Yes this should be 0 < n < 256.
>
> negatable<16,-8> -65536 < n < 65536 in increments of 2^-8
>  = 1/ 256
>
> This seems close to a fixed point type as I'm used to seeing it. 
> Although again the ranges seem wrong.
This depend on the definition. With the definition in 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html this 
is correct.
>
> I'm much more accustom to seeing fixed point number specified as 
> <Magnitude bits, Fractional Bits> i.e. <16,8> instead of <16,-8>.

The problem I see with this notation is that to represent the numbers 
-65536<n<65536 in increments of 2^8=256 you need to use a fractional 
bits that is negative, which is in some way counterintuitive with the 
name of the template parameter, or maybe we need to find a name for 
which a negative number is intuitive.
> Still this representation makes sense because it specifies both 
> parameters in terms 2^x. It also supports something like <17,1> to 
> give a 16 bit type that has the range [-131072, 131071] in increments 
> of 2.
>
> Still it might be surprising to those familiar with the more common 
> fixed-point notation.
>
As I said there are several notations and there is no real one that 
would make happy everyone. So I think that the library should take in 
account this point and provide some aliases (c++11)/type traits(c++98) 
for the most common notations.

Choosing the default notation is critical and having a consensus on it 
would be difficult. Do you think that it is worth proposing several 
default notations and request the boost community to choose the default one?

Best,
Vicente