[MPlayer-dev-eng] Patch for gcc 3.4 against MPlayer-1.0pre5

[D Richard Felker III]

On Thu, Sep 02, 2004 at 03:29:07PM +0200, Torinthiel wrote:
> On Thu, Sep 02, 2004 at 02:06:01PM +0200, Michael Niedermayer wrote:
> > from 'info libc'
> > ----
> > Round to nearest.
> >      This is the default mode.  It should be used unless there is a
> >      specific need for one of the others.  In this mode results are
> >      rounded to the nearest representable value.  If the result is
> >      midway between two representable values, the even representable is
> >      chosen. "Even" here means the lowest-order bit is zero.  This
> >      rounding mode prevents statistical bias and guarantees numeric
> >      stability: round-off errors in a lengthy calculation will remain
> >      smaller than half of `FLT_EPSILON'.
> 
> Now this is more specific. But also quite strange. I don't want to argue
> against specs, but AFAIK numbers are coded as sign*0.1(mantissa)*pow(2,exp)

0.1?!? wtf? 0.1 is not even representible as a float, it takes
infinitely many places in binary...

> where sign, mantissa and exp are stored in memory and fraction is
> a binary one, not decimal. (mantissa binary, exp decimal)
> So, 1.5 (mantissa 1, exponent 1) would round to 1 (mantissa 0, exp 1)
> but 3.5 (mantissa 11, exponent 2) would round to 4 (mantissa 0, exp 3).
> Or am I wrong somewhere? This is some random rounding as I see it.

you're wrong. 1.5 and 3.5 both round to _even_ numbers, so they round
to 0 and 4.

> > > And if I would like lrintf(0.3) to be 1, then I would use ceil(0.3).
> > > Not fesetround(FE_TOUPPER); lrintf(0.3). It's faster IMHO, as no
> > > setting in fe* is done and no checking in lrintf.
> > no, ceil() == fsetround();lrintf();fsetround() on x86 at least
> 
> You say effect or implementation?
> If implementation than libc suffered from some severe disoptimization.
> Ceil was defined looong before lrintf if my knowledge is correct.

um, he's not talking about the c99 function calls but the equivalent
asm. to do ceil, libm has to put the cpu in a different rounding mode,
round, then restore the old rounding mode.

> Anyway, is it still revelant?
> Problem was that different versions returned different values.
> So lets just decide which one is better and make both return it.

round-to-even is better.

rich