
Boost : 
Subject: Re: [boost] [fixed_point] Request for interest in a binary fixed point library
From: Neal Becker (ndbecker2_at_[hidden])
Date: 20120411 19:34:30
Vicente J. Botet Escriba wrote:
> Le 12/04/12 00:25, Neal Becker a Ã©crit :
>> Vicente J. Botet Escriba wrote:
>>
>>> Le 11/04/12 14:37, Neal Becker a Ã©crit :
>> ...
>>>> * fixed point<> flt should be provided. fixed.as_double() for example.
>>> Should the
>>>
>>> fixed point > flt conversion take care of the rounding policy?
>>>
>> In my prototype code, every time a right shift is used, rounding policy is
>> applied.
>>
>> rounding policy is a template parameter, with one default (the only one I
>> care about).
>>
>> The default is,
>> template<typename base_type=int>
>> struct rnd {
>> static base_type apply (base_type x, int frac_bits) {
>> return ((x>> (frac_bits1)) + 1)>> 1;
>> }
>> };
>>
>> To shift right by 'frac_bits' places, with rounding, we shift right 1 less
>> place, add 1, then shift 1 more place. When followed by saturation, this is
>> the most common rounding operation I use for 2's complement hardware.
> I want the library to avoid myself to apply these explicit operations. I
> don't want to see on my code a shift to apply a round. IMO rounding
> should be applied when the resolution decreases during a conversion and
> the shift must depend on the difference and the rounding policy.
>>>> Also,
>>>> fixed (double, integer_bits, frac_bits) constructor, or something like it.
>>> Could you be more precise, please?
>> I want to be able to construct a fixed from a float, specifying the number of
>> integer and fractional bits (or equivalent).
>>
>>
> I don't understand. If the fixed_point type conveys the number of
> integer and fractional bits, why do you want to give them as parameters
> of the constructor?
>
Sorry for the confusion: my comment was about runtime specified fixed point
type. If using compiletime specification of integer and fractional bits, then
you're correct  no need for those constructor parameters.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk