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

[Michael Niedermayer]

On Wed, Jan 27, 2010 at 06:58:38PM +0200, Uoti Urpala wrote:
> 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.

if you assume a reasonable implementation and assume the
input is exactly representable and the output is exactly representable
and you didnt make a mistake like not considering that some intermediate
might not be exactly representable ...


in practice just try cos(M_PI/3.0 + i*M_PI) though
the input i surely is exactly representable also the output is ...


> 
> > 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).

with gcc but with other compilers that is not neccesarily so


> 
> > 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.

try:
printf("%20.20f %20.20f\n", 0.4999999999999, (float)0.4999999999999);


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100127/7a2cb40e/attachment.pgp>