Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug

Hi again KHMan,

> On the bigger/smaller, I thought Kahan made sure you can still
> integer-compare them floats and doubles...

No, you can't (not easily at any rate): I'm in production scheduling 
(among many other things), and you can be as well five minutes from the 
start as you can be three years later - no way to encode that range into 
ints (not even _i64s). Now here's the thing: I can accept the 
imprecision at three years (it's a LONG prediction anyway!)... but I 
*can't* accept that it would be seemingly different (even if it's not!) 
across compilers, just because it's printed differently: how should I 
debug that??
I found Tei's idea extremely compelling to us: whatever the binary 
contents of the float, it should be printed in decimal the same way 
whatever the compiler. Of course, only about seven of the digits are 
really relevant in a float... but whatever they are, they should be 
*printed the same* for the sake of comparisons. It's a GOOD IDEA - and 
he solved it. He sure may not have been the first, but he was willing to 
share his code here, and I believe he deserves thanks for that.

Have a great day!


On 18-Jan-17 05:35, KHMan wrote:
> On 1/18/2017 11:39 AM, Emanuel Falkenauer wrote:
>> Hi KHMan,
>> Ok, apologies accepted! Above all, I hope Tei feels better...  :-)
>> I've been long enough in HPC to know that floats are of course not ideal
>> - but when you need to allocate dozens of Gigs of data to hold info for
>> dozens of threads running at the same time, they do become extremely
>> valuable as an alternative to doubles (not to mention long doubles)
>> because of their modest size.
>> But printing them has always been a pain in the neck - of course I
>> figured out already in the 80-ties that you can print their binary
>> contents instead, but it's really horrendously time consuming to then
>> try to figure out "Oh my, is 0x0EA478A9 bigger or smaller than whatever
>> in float?" Tei's code solves that problem for me once for all and across
>> compilers, and I'm sure grateful for that help.
> Good to know. I always got the impression that David Gay's
> implementation was spread everywhere, hence, getting consistent
> ASCII representation is not prohibitively difficult. On the
> bigger/smaller, I thought Kahan made sure you can still
> integer-compare them floats and doubles...
> To avoid misunderstanding if others are reading, here is my
> rethinking: I presented a lot of general arguments about usage of
> floating point, hence, talk of errors and such. Finally Tei's
> mention of Bruce Dawson's blog post brings clarity into the
> problem at hand. Bruce's work appears to be on ASCII
> representation portability, safety, etc. He is also exploring
> representing floating point in ASCII perfectly consistently
> (although round-tripping is not an issue even if ASCII
> representation is not the same for every platform), stuff like that.
> It may appear that the arguments are of different areas, or
> talking past each other. I think Tei is somehow in a mixup. Bruce
> generated these long lengths of digits in the effort to check
> ASCII representation. But in the end he recommended the usual 9
> digits for floats anyway. The extra digits (for example, in the 19
> digits Tei used in his test) are only 'good' in one direction, 1.0
> ==> some float. But that float can represent more than that exact
> 1.0. So in the end 9 digits is fine, we did not see a problem at
> all, no bug. So I sincerely hope that Tei can reevaluate his
> reasoning.
>> As I said: issue settled, no hard feelings left. Have a great day!

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