[FFmpeg-devel] [PATCH] HE-AAC v1 decoder
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
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel