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

[Martin Simmons]

>>>>> On Thu, 2 Sep 2004 15:29:07 +0200, Torinthiel <torinthiel at megapolis.pl> said:
> 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)
> where sign, mantissa and exp are stored in memory and fraction is
> a binary one, not decimal. (mantissa binary, exp decimal)

Nearly -- it is actually more like sign*(mantissa-1)*pow(2,exp) 
where 1 <= mantissa < 2.
In binary terms, this means that the mantissa always starts with a 1, which
isn't stored.


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

Rounding to even is just a special rule for halves, not anything you can
deduce from the binary mantissa.

__Martin