This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]