[FFmpeg-devel] [PATCH] HE-AAC v1 decoder

[Uoti Urpala]

On Wed, 2010-01-27 at 17:34 +0100, Michael Niedermayer wrote:
> On Wed, Jan 27, 2010 at 11:15:23AM -0500, Alex Converse wrote:
> > *round*() family functions round their argument to the nearest integer
> > value, rounding away from zero, regardless of the current rounding
> > direction. *rint*() uses the current rounding direction. There are a
> > few cases where things can end up at exactly 0.5 and it makes a big
> > difference.
> 
> then the code is broken, floats are not exact, especially not floats in
> C. floats in ASM might be useable like that but in C assuming that a
> calculation like lround(a/b) will have a 0.5 result rounded the way
> lround should is russian roullet.

They're not that "inexact". The biggest issue causing uncertain behavior
in practice is the x86 extra precision (by default GCC keeps variables
in the long double-precision FPU registers, and it's unpredictable at
which point they lose that precision due to being spilled to memory).
However no such precision issues affect calculations that produce an
exactly representable value like 0.5 from values that are also exactly
representable. Any reasonable implementation will give that exact result
and nothing else.

> you only need a lround(c/b) close by and many compilers includig gcc
> will calculate x=1/b and do lround(a*x) and lround(c*x) also

With default options it will not. Such unsafe optimizations are only
enabled by -ffast-math (this one more precisely by -freciprocal-math,
which is implied by -ffast-math).

> the compiler can choose to keep values in registers that are more
> precisse than doubles or store as floats in intermediate memory loctions
> Code that depends on the rounding direction of 0.5 definitly is a
> time bomb.

Precision makes no difference here.