Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug

On 2017-01-20 08:17+0100 Emanuel Falkenauer wrote:

I said:
>> @Emanuel:
>> Floating-point representations and calculations are exact for a
>> subset of floating point numbers (e.g., positive or negative powers of
>> two times an integer). But if you are using arbitrary floating-point
>> numbers in your calculations, then I frankly cannot understand your
>> result since time and again I have seen examples where compiler
>> optimization changes the answer in the 15 place (if you are really
>> lucky and it is often much worse than that if you have any
>> significance loss which is a common problem if you are solving
>> solutions of linear equations). Also consider a number similar to
>> 0.4321499999999999999999999 which rounds to either 0.4321 or 0.4322
>> depending on minute floating-point errors.  If such numbers appear in
>> your log output even heavy rounding is not going to make your logs
>> agree for different optimization levels.  Perhaps your logs have no
>> arbitrary floating-point numbers in them and instead actually contain
>> exact floating-point answers (such as integers, half-integers, etc.)
>> or no floating-point decimal output at all?  For example, your log
>> could simply say that a certain category of answer was achieved
>> without giving exact details, and you should indeed get that same
>> result regardless of optimization level if you are well-protected
>> (e.g., make no logical decisions based on floating-point comparisons)
>> against floating-point errors.
Emanuel replied:
> I do see what you're getting at, and frankly I grappled with those same
> issues myself as well (huh: about 20 years ago). But I realized one
> FUNDAMENTAL thing: the "minute floating-point errors" you refer to are
> NOT RANDOM - they're products of well-defined computations done by the
> FPU, which these days is normally IEEE-compliant, at least as basic
> operations are concerned (I'm not talking about sqrts and such, which
> might well be proprietary). Ergo they MUST yield EXACTLY the same
> results (bit-wise), or the IEEE standard is useless. I mean... it's not
> as if a FPU had a Schrödinger cat embedded!
> Yes, sometimes the results are a bit surprising (e.g. your
> 0.4321499999999999999999999 instead of 0.43215)... but that doesn't
> bother me a bit AS LONG AS the same "surprise" is produced by every
> build I produce with whatever toolchain (MinGW, Borland... I even made
> our code bitwise-compatible with MS Visual C++! [To no avail, btw: it's
> slightly SLOWER than the excellent MinGW craft.]).
> Sure, those "surprising" results need to be managed (which we do in our
> algorithms) - but apart from that, the behavior should be EXACTLY the
> same across toolchains - and the latest KHMan's post confirms that
> conviction. Ergo it's perfectly reasonable to print those values in my
> comparison logs - AS LONG AS the same binary float is always printed the
> same decimal way. That was an annoying problem for us... until now.

Hi Emanuel:

I took KHMan's post with a bit of a "grain of salt" because those
references did not say explicitly (although they could be interpreted
that way) that you are guaranteed the same floating-point result with
Linux gcc regardless of -O optimization level.  And historically the
PLplot results were a definite counter-example to that idea.  There,
our PostScript 64-bit floating-point result for plots (heavily rounded
to 4 places, hence my example above) did differ (but only
occasionally) in the last of those 4 places from one optimization
level to another, and at that time I ascribed that result to the above
model of the (rare) propagation of small errors in the ~15th figure to
heavily rounded results.

But since you don't seem to be encountering such issues yourself with
modern Linux gcc, I tried the experiment of generating PLplot results
for all our C examples with our PostScript device with the Linux gcc
(Debian 4.9.2-10) compiler using both -O0 and -O3, and indeed the
results are identical (for 33 standard plplot examples representing
several hundred pages of plots so it is an extensive test)!  So it
appears the conclusion must be that floating-point calculations are
done in much more consistent ways now with gcc for both your case and
this recent PLplot test , and I intend to double-check that
(unexpected for me) conclusion for the timeephem and FreeEOS projects
where results are not so heavily rounded as those of PLplot.

However, for whatever reason (e.g., everyone might now be using the
same IEEE floating-point calculation algorithms) assuming this
floating-point consistency is now true for most compilers (so long as
no optimization is done other than the normal -O0 through -O3
options), that is an important floating-point breakthrough that would
make comparisons of results from one compiler to others _much_ simpler
(as you have already discovered for your software project).
Furthermore, if care was used to not gratuitously mess with the order
of computations from one software release to the next, this
breakthrough should also simplify consistency testing of results for
various software versions.

Finally, to drag this post back on topic for this list, I haven't paid
much attention to earlier posts in this thread, but assuming from your
subject line this floating-point consistency is not currently
available for any unpatched official release of the MinGW version of
gcc, this inconsistency is something I would strongly encourage the
MinGW developers to address to aid such important cross-platform
consistency testing.

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).

Linux-powered Science

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list

This list observes the Etiquette found at 
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

You may change your MinGW Account Options or unsubscribe at:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe