Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug




Hello Alan,

On 20-01-17 04:55, Alan W. Irwin wrote:
> Interesting thread. 

Glad you enjoy it. To be very honest, I have never expected it to be 
blown into those "interstellar" proportions... but, well, there ARE some 
pretty fundamental computational issues in stake.

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

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.

>
>>> Emanuel - The one thing I cannot grasp is that you have built s/w with a
>>> range of toolchains, but you are very focussed on obtaining exactly the
>>> same numerical answers - seemingly to the level of false precision - for
>>> each build.
> @ Everybody:
>
> Here I have to agree with Emanual that sometimes such a result is
> desireable for testing purposes.  One example of this I have run into
> is the positions and velocities of the planets (planetary ephemerides)
> that are distributed by JPL in both binary and ascii forms.  So when
> converting between the two forms for debugging purposes you would like
> to start with the binary form (64-bit double precision IEEE floating
> point numbers) and be able to convert to ascii form and back again
> with no bit flips at all in those binary results.  It turns out that
> with gcc on Linux and the Linux C library that with x86_64 hardware
> (where intermediate floating-point results are stored in 80-bit
> registers) that this result was obtained. Apparently the C library
> converted the binary format to ascii decimal format with sufficient
> additional (likely 80-bit) precision so that the result was exact to
> something like 20 places.  And if my ascii representation included
> those ascii guard digits that was sufficient so the result could be
> converted back exactly to the 64-bit floating-point representation. I
> could also take the ascii result distributed by JPL (which apparently also had
> sufficient guard digits likely because they were using x86_64 hardware
> with a decent C library that took advantage of that 80-bit
> floating-point precision) and convert those results to their
> distributed binary form exactly.  So that was a very nice round-trip
> test result for extremely large masses of floating-point numbers.
>
> By the way, I tried the same round-trip binary to ascii to binary
> ephemeris test using MinGW gcc on Wine, and the upshot was I
> discovered a bug (#28422) in the scanf family of functions implemented
> for Wine (they were actually using 32-bit floating-point numbers for
> the conversion at the time so it was a significant bug) that they have
> subsequently fixed.  And after that Wine fix my round-trip test worked
> for that platform as well.

Extra-cool! :-)

> In sum, if you have some scanf-type conversion from ascii to binary
> representation of floating point or some printf-type conversion from
> binary to ascii representation of floating point that is not done
> using the maximum possible precision for the hardware, types like
> Emanual and me who are keen on testing will come back to haunt you!
> :-)

Oh yeah: haunting indeed!  :-)

Cheers,

Emanuel


> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
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
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe