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
>>> How can I improve it?
>>> I appreciate any feedback you may have.
>> <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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk