Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug

Hi Keith,

On 19-Jan-17 01:36, Keith Marshall wrote:
> 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
> alternative?

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!



> - -- 
> Regards,
> Keith.

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