Re: [Mingw-users] msvcrt printf bug
On 19-Jan-17 01:36, Keith Marshall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 18/01/17 23:34, Emanuel Falkenauer wrote:
>> Trouble is, it's NOT trivial to stop before that limit with printf.
>> Sure, I could print %.2f when the two digits are the only valid ones,
>> but that would prevent me from correctly printing e.g. 0.00001234 so
>> that it would show differently from 0.00001236 (even though both
>> only have four significant digits). I simply didn't find a reliable
>> way of printing those floats when they vary by orders of magnitude.
> "%.2f" doesn't specify significant digits -- it specifies digits
> after the radix point. If you want to see, and compare, just so
> many significant digits, you would surely be better off using
> "%.2e", (so you don't get the leading insignificant zeros).
I got that, don't worry. ;-)
> One other potential issue, which I neglected to mention: when you
> perform floating point calculations you may suffer rounding, or
> even cancellation effects, all of which conspire to make even less
> than the absolute maximum representable precision available. This
> may be further compounded by differing FPU configuration between
> implementations -- e.g. it is my understanding that Microsoft
> configure the FPU to operate in 8-byte register mode, whereas
> GCC uses full 10-byte capability. Such configuration differences
> could lead to rounding differences, even within the available
> 53-binary/15.955-decimal digit precision limit.
I agree with all you said there (and am well aware of it), but it does
turn out that I DO get identical results (thanks to the IEEE standard, I
would guess - and the fact we're running both builds on the same machines).
Now just to explain the extent of it, so you know what I'm talking
about: we're in the business of assembly optimization in large
aeronautic companies. The algorithm in question is a genetic algorithm
(i.e. an iterative and evolutive process) and depending on the size of
the data (which are usually pretty fat), it often runs for dozens of
hours in 16 threads at full throttle - that's literally TRILLIONS of
floating point calculations (including some divisions that we can't
eliminate) in a single run, and any drift due to different rounding etc.
would accumulate over the time.
Yet STILL, the Borland build ends up with exactly the same results as
the MinGW build, even after hours of running. It's pretty remarkable
indeed... and makes our debugging so much easier. But rest assured that
that consistency is also the result of an enormous effort (including
fiddling with the FPU flags) on our part to ensure portability.
>> I would LOVE to use _your_ printf... but remember: the whole story is
>> about comparing with Borland builds, where it's not available.
> Well, you are always likely to be on a hiding to nothing, when
> you compare apples with oranges, and expect identity -- in this
> case, how can you possibly expect consistency between Borland's
> proprietary (likely undisclosed) algorithm and A. N. Other's?
Well, given the above, I would rather say that they are just oranges of
different varieties. ;-)
> If you want guaranteed consistency, you'd better use identically
> the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
Honestly, I expect the sources (if I can have them) to be littered with
external references that do not exist in Borland, making the port really
painful. I have once debugged Thunderbird (because it ceased to function
and I needed it sorely - I actually found the bug! :-) ) and that was a
dreadful experience... so I would expect something similar in porting
MinGW's (s)printf to Borland.
But, well, maybe I'm wrong - can you instruct me how to get hold of your
(s)printf sources? Many thanks!
> - --
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: