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

Michael Niedermayer michaelni
Fri Feb 5 22:19:44 CET 2010

On Wed, Jan 27, 2010 at 08:31:18PM +0200, Uoti Urpala wrote:
> On Wed, 2010-01-27 at 18:41 +0100, Michael Niedermayer wrote:
> > in practice just try cos(M_PI/3.0 + i*M_PI) though
> > the input i surely is exactly representable also the output is ...
> Of course you can break things if you add arbitrary intermediate
> steps...

So what you say is now just that things are safe in practice when
* the input is integer
* the output is exactly representable as an integer
* the operation is atomic in the hardware
* the compiler chooses to use the atomic implementation and for
  example doesnt break pow(x,y) in exp(y*log(x))
* the atomic implementation in the hardware is exact.

Thats alot of assumtations, some of which likely arent true in all cases
that exist in that patch on all platforms we support.
Or simpler, lets just do what i originally suggested and use integers :)

> > > > 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);
> That does not rely on the rounding direction of 0.5 (or any calculation
> producing 0.5), but on the behavior of a different number. If you're
> talking about calculations that lose precision in general then those are
> unlikely to be reliable at any particular precision unless the code has
> been carefully crafted for that.

well no, there is no different number, its just 
as example you could use roundf(func(i));
func(i) == 0.4999999999999

this can produce 0 or 1 depending on if the compiler keeps it in a register
or not, it also depends on the rounding direction of 0.5 because if thats
down then the result is always 0

In summary i think this discussion is quite pointless, it should be clear to
anyone who knows about integer & float math that floats are a bad idea if
binary reproduceable results are desired. It may work with some expressions
on some platforms and some compilers but it can break on tomorrows compiler
and platform. Theres nothing in the specs that require the behavior you
consider reasonable.
And above all we have a perfectly better option, integer math so theres
absolutely no point in discussing if some expressions are more likely to
work out binary identically.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20100205/a0c6aa1d/attachment.pgp>

More information about the ffmpeg-devel mailing list