Re: [Mingw-users] msvcrt printf bug
- Date: Wed, 18 Jan 2017 12:35:09 +0800
- From: KHMan <keinhong@xxxxxxxxx>
- Subject: Re: [Mingw-users] msvcrt printf bug
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
> As I said: issue settled, no hard feelings left. Have a great day!
Kein-Hong Man (esq.)
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: