This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: linux i-86 problem with rounding (gcc-3.1.1 & 3.2)
- From: Martin Dickopp <firefly-mail at gmx dot net>
- To: "Hillel (Sabba) Markowitz" <sabbahem at bcpl dot net>
- Cc: GCC Help <gcc-help at gcc dot gnu dot org>
- Date: Wed, 18 Sep 2002 20:56:09 +0200
- Subject: Re: linux i-86 problem with rounding (gcc-3.1.1 & 3.2)
- References: <3DA4DFFD@webmail.bcpl.net>
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