RE: linux i-86 problem with rounding (gcc-3.1.1 & 3.2)

["Buddy Lott" <buddy_lott at hotmail dot com>]

While I agree, that processor type would affect the precision of the
answer, I would think the compiler should consistent when optimizing/not
optimizing code. I would think it should never change the result of the
code.

In either case, I always stand by the rule that specifically defining
what you want is always better the relying on a default that might
change.

On the other hand....

To be a little more picky about this question, I would ask in what
domain this problem is in. That would define what the "proper" handling
of the rounding is.

I seem to remember that in the science arena, there are specific rules
as to when and how you round.

Bear in mind also, that rounding too early can cuases the margin of
error to increase as the value is used.

Take for instance (this is contrived):

float i = .5;
int x = 3;
int z= 5;
int n;

n = (int) ((x * i) + .5) // result is 2 if I round here
n = n*5; // result is 10

n = (int)((x*i*z) + .5) // result is 7.5



> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]
On
> Behalf Of Martin Dickopp
> Sent: Wednesday, September 18, 2002 1:56 PM
> To: Hillel (Sabba) Markowitz
> Cc: GCC Help
> Subject: Re: linux i-86 problem with rounding (gcc-3.1.1 & 3.2)
> 
> On Wed, Sep 18, 2002 at 02:39:32PM -0400, Hillel (Sabba) Markowitz
wrote:
> > >===== Original Message From Martin Dickopp <firefly-mail@gmx.net>
=====
> > >  u = (unsigned int) (i*f + 0.5);
> >
> > Actually, I think it would have to be u = (unsigned
> int)(floor(i*f+0.5));
> > just to make sure that the default round is not to the nearest
integer.
> 
> No, that is not necessary. To quote the ISO C Standard (Section
6.3.1.4):
> 
> | (1) When a finite value of real floating type is converted to an
> | integer type other than _Bool, the fractional part is discarded
> | (i.e., the value is truncated toward zero). If the value of the
> | integral part cannot be represented by the integer type, the
> | behavior is undefined.
> 
> > The question was not that I assume that the rounding was infinitely
> precise,
> > but that the rounding from the same floating point value was
> inconsistent only
> > on one platform.  Additionally, the rounding from u = (unsigned int)
> (i*f);
> > was not the same as the rounding from g = (i*f); u = (unsigned
int)g;
> >
> > Additionally, the -O option in the compilation caused the rounding
error
> to
> > disappear, something that does not seem reasonable.
> 
> Yes, the imprecisions that appear in floating-point calculations can
> depend, amongst other things, on the processor type and optimization
> level. Even if you do the same calculation twice within the same
> program, there is no guarantee that the results will be exactly
> identical.
> 
> Martin