[Speex-dev] Speex inner_prod()

[Jean-Marc Valin]

Hi,

Basically, inner_prod() can and should be adapted to the architecture it
will run on. It is not really sensitive to noise, so it's possible to
tweak it a lot. Also, in the current code, I saturate it to +-16384,
which is OK to prevent overflows. I'm not concerned with the case of a
constant -16384 value because it can't really happen in practice
(especially after filtering). BTW, on platforms that have a 40-bit
accumulator, it's possible to even remove the shift from the loop and
apply it only at the end.

Le vendredi 03 février 2006 à 11:27 -0600, Jerry Trantow a écrit :
> I am overriding the inner product routine in ltp.c.  To test my replacement,
> I threw some test vectors at it.  I understand the loss of resolution caused
> by the shift.  I also see a FIXED_POINT danger with the summation of four
> mults overflowing the 32 bit before the shift.  
> 
> I can fix this by accumulating each term into a long, but if the code scales
> the x[],y[] vectors to avoid this problem I could use parallel 16x16
> multiply/adds.  

What do you mean here?

> You can see this problem with the following test case.
> 
> for (i=0;i<40;i++)
> {
> 	x[i]=-16384;
> 	y[i]=-32768;
> }

The value -32768 is not supposed to happen in vectors sent to
inner_prod.

> sum0=inner_prod(x, y, 40);
> fprintf(stderr,"inner_prod0(%8d).\n",sum0);

	Jean-Marc