
Boost : 
From: John C. Femiani (john.femiani_at_[hidden])
Date: 20080801 07:42:01
Matt Gruenke wrote:
> John C. Femiani wrote:
>> Matt Gruenke wrote:
>>> Speaking of division, while I'd expect /= to return the same type as
>>> the LHS operand, the way I've previously implemented fixed point
>>> division is to return:
>>> result_int_bits = (numer_int_bits + denom_frac_bits + 1)
>>> result_frac_bits = (numer_frac_bits + denom_int_bits  1)
>> So then what happens to the value of X after I say Z = X /=Y?
>> Do you mean '/', instead of '/='?
>
> Yes, I was describing the behavior of my operator/(). I hadn't
> written an operator/=().
>
I think perhaps the issue with division is that rounding policy should
be rethought. Also:
> base_type tmp = (base_type)val / (base_type)x.val;
> val = tmp << (frac_bits);
should be something like
static const int DENOMINATOR= 1 << frac_bits;
base_type tmp = rounding_policy::divide(val * DENOMINATOR, x.val);
I think the old way lost a lot of precision because it divided before
multiplying.e.g.
Then for multiplying:
> base_type tmp = (base_type)val * (base_type)x.val;
> val = tmp >> (frac_bits);
could possibly be:
val = rounding_policy::divide( val * x.val, DENOMINATOR);
Another way to think of it is that the rounding policy should be a part
of the base_type, decoupled from the fixed pt class.
Then one can just assume that
val * x.val / DENOMINATOR
rounds the way the user intended.
You can provide separate wrappers that change the bounds as well as the
rounding behavior, and your code should be less coupled.
To create a fixed point class, I could say:
fixed_pt<8,24, bounded_int<int, MIN, MAX, true, true> >
or
fixed_pt<8,24, with_rounding< nearest, bounded_int<int, MIN, MAX,
true, true> > >
assuming that you had a template class called 'with_rounding' and a
struct for the 'nearest' rounding policy.
You can follow the trend of the constrained_value authors and make
'nearest' a function, so that ::boost::function can be used and the
rounding policy can be changed at runtime.
John
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk