# Re: [Mingw-users] msvcrt printf bug

*Date*: Wed, 18 Jan 2017 21:39:22 +0000*From*: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>*Subject*: Re: [Mingw-users] msvcrt printf bug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guys, This thread now seems to have run its course; sadly, the level of pervasive wide-spread ignorance it has demonstrated is depressing. On 18/01/17 10:00, tei.andu@xxxxxxxxxxxx wrote: > Emanuel, thank you very much for stepping in. I am extremely happy > that you found my code useful. Great that he finds it useful; depressing that neither of you cares in the slightest about accuracy; rather, you are both chasing the grail of "consistent inaccuracy". (I don't have a problem with that, as objective, but please do not claim that it represents "accuracy"; it is entirely speculative; anything but accurate). > I started learning C by myself in 2010. I work in embedded, > specifically digital power conversion and industrial control > systems. KH Man, thank you for your advice again. I am not a student, > but I am still learning. And still have much to learn, apparently, especially regarding the representable precision of floating point numbers. > I agree that this a non issue for most users. For me the matter is > closed. I will use cygwin when I need a more accurate printf. You don't need to do that -- just compile your MinGW code with any of the options, or define any of the feature test macros, which enable our alternative printf() function suite, and you should get output which is just as consistently INACCURATE as cygwin's, (for, AFAIK, the conversion algorithm employed is the same). Yes, I deliberately said "consistently inaccurate"; see, cygwin's printf() is ABSOLUTELY NOT more accurate than MinGW's, (or even Microsoft's, probably, for that matter). You keep stating these (sadly all too widely accepted) myths: > Every valid floating point representation that is not NaN or inf > corresponds to an exact, non recurring fraction representation in > decimal. In the general case, this is utter and absolute nonsense! Sure, there are a few cases where it may be true -- cases which are limited to those where the number of significant decimal digits generated does not exceed the representable precision of the available binary digits within the underlying data type, AND the significant digits of the represented value, when considered as an unsigned integer, (after conversion of the exponent from base two to base ten), are evenly divisible by ten, with no remainder. In ALL other cases, (by far the majority), the value represented is INEXACT. > There is no reason why printf shouldn't print that exact > representation when needed, as the glibc printf does. Pragmatically, there is every reason. For a binary representation with N binary digits of precision, the equivalent REPRESENTABLE decimal precision is limited to a MAXIMUM of N * log10(2) decimal digits; for the standard data types, this equates to: - - 4-byte (float): 24 binary digit precision = 7.225 decimal digits - - 8-byte (double): 53 binary digits = 15.955 decimal digits - - 10-byte (long double*): 64 binary digits = 19.266 decimal digits [*] MSVC, (hence MSVCRT.DLL), does not support 10-byte long double data type; their "long double" is indistinguishable from 8-byte double. Now, for RELIABLY ACCURATE output, we CANNOT achieve any better than floor( N * log10(2) ) decimal digits of precision. Sure, you can generate more, by appending arbitrary less significant binary digits to the original representation of the value; for each such extra binary digit there are two (equally valid) choices, so you increase uncertainty in the output value by a factor of two for each such digit -- and by a factor of ten for those extra bits required for each full decimal digit added, after the bits of the actual original representation have been exhausted. Thus, your claimed accuracy, in those extra digits, is bogus; it trails exponentially to zero, as you add more of them. In reality, you are representing just one of an (ultimately) infinite number of alternative realities, each equally valid, (and each equally fictitious), depending on what specific, arbitrarily chosen bit pattern you adopt, to extend the limited representation from which you started, (and which is the extent to which anything realistically accurate is actually known). Incidentally, you do make a valid point regarding conversion of INPUT from string to binary. Take the 4-byte float, for example: its maximum reliable OUTPUT precision is only seven significant decimal digits, but seven decimal digits is insufficient to fully represent the full 24 binary digits within the underlying float data type -- you need 7.225 (realistically eight) decimal digits for that, and nine are recommended to address potential rounding disparity. Thus, if your output is to be read back, so as to generate identically the same binary representation, you will likely need to emit two digits beyond the maximum reliable output precision. That's absolutely fine, provided you understand that these extra digits are dependent on some arbitrary choice, and do not represent significance in the original data -- you certainly have absolutely no justification for claiming them to be "accurate". - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYf+CKAAoJEMCtNsY0flo/76kP/3GwD0DN1QCoprpiwG8PWN1W Anx73Nql4ltUXwVL/UgVD3TJcZTNqgI8n4x0kWy9qKGZoU/xdimBB6JdeWfQljgR ZcfUJD/w5HOley1SGIfq0CZYRX2GI8sbNVrQYsPvZUo4OTR5PXC4FBDi+o9vAo5F 3dyZphHXzqP7BT2xyoT9vS83anYYIFVdvjB78kH7MYeYjB/CywV698MBJmrrrv4c 42WqTEQEQFGi4fpQxraV4eJS0Jxp6fmsYD722Tq9mIR309ZO5lCxQHE/kwAaVC6L YQldAnn8i/yyX4rGT9/8vAcZrHwekVopqq0xOVQRjL2r3iDkvECWrdeyoyDnj43L EOJ3iNasqNT/EdqaHEHRCVT1dMdl9xNmiZH+5AeW3SYP9ecm5sjqMEDpFiF2RlCS oCToQY07UeECjk+AK+fSG41xE2LV/DsuEQeuy+0qngwN/hGt51+g4QGep3XMMzm9 5DXGYAIdBzZIcMFwS2bALjQG1DjYqDULr8DWR3+3YG4/ECxuoAIF5n19Dm5alpsm QbA6GQ/IlMh7ylXWAbja5W/UWk+Bn6WW71VJLuluHn8wSlN91uGebyH8iO++u7pJ 0zQCRPKKRx51UQAVERGVxJKdp2zu7tw4pLdbLMiR6ayv+4UeyE34r9lhjUKLvuVx V2uWeYywxARlTU0gHNvm =mtXs -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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

**Follow-Ups**:**Re: [Mingw-users] msvcrt printf bug***From:*Emanuel Falkenauer

**References**:**Re: [Mingw-users] msvcrt printf bug***From:*tei.andu

- Prev by Date:
**Re: [Mingw-users] msvcrt printf bug** - Next by Date:
**Re: [Mingw-users] undefined reference to _imp__*** - Previous by thread:
**Re: [Mingw-users] msvcrt printf bug** - Next by thread:
**Re: [Mingw-users] msvcrt printf bug** - Index(es):