Boost logo

Boost :

Subject: Re: [boost] Fixed point implicity
From: Ravi (lists_ravi_at_[hidden])
Date: 2009-07-02 09:56:37

On Thursday 02 July 2009 08:25:11 Neal Becker wrote:
> I completely agree with the sentiment (explicit is better than implicit),
> but I would (and have) done it differently:
> N @ N -> N.
> If you want different, you cast the operands to wider field first.

Too hard to use correctly, in my experience. For example, during DSP algorithm
development, I have a function that computes something:

template <typename A=double, typename B=double, typename C=double,
          typename R=double>
R compute_cmag( A a, B b, C c)
  return R( (a*(b+c))*(a*(b+c)) ); // grouping necessary for hardware model

After algorithm development, during fixed point conversion (for implementation
on a chip), I find that the following suffices:
  A = s[2,-3] 7 bits
  B = s[4,-2] 8 bits
  C = s[4,-3] 9 bits
  R = u[7,2] with saturation and truncation 6 bits
where s[a,b] is a signed type holding bits for 2^a, 2^(a-1),...,2^b and u[a,b]
is the corresponding unsigned type.

In generic code of the form above, I do not want to compute the largest type
required for all intermediate computations, since the compiler can do it for
me. In fact, I do not even want to know whether the intermediate precision is
larger than what can represented by fixed-point numbers, since I expect the
compiler to give me an error if the intermediate precision becomes too large.
There are likely to be hundreds of such computations in a model for, say, a
demodulator, and I definitely do not want to go through every single one of
them trying to compute maximum intermediate precisions (unless the compiler
tells me to do so).


Boost list run by bdawes at, gregod at, cpdaniel at, john at