Web lists-archives.com

[Mingw-users] msvcrt printf bug




Hello,
Thank you for replying. My attached C file was scrubbed. I am sorry, I am new to mailing lists.
It was just asigning 0x5D5F27A4 to a float - uint32_t union and printing the float with printf.

KHMan: I think you are wrong here. Every valid floating point representation that is not NaN or inf
corresponds to an exact, non recurring fraction representation in decimal. There is no reason why
printf shouldn't print that exact representation when needed, as the glibc printf does.
For instance:
0x5D5F27A3: 14624675 * 2^(59 - 23) = 1005000013434060800 this prints correctly with msvcrt printf
0x5D5F27A4: 14624676 * 2^(59 - 23) = 1005000082153537536 this prints wrong with msvcrt printf for me: 1005000082153537500. Larger values also print slightly off.
We are talking about whole numbers here, fractional part is zero.

An acceptable loss in precision occurs when converting from a decimal representation to a float number due to limited precision in float:
0.1 is closest represented by 0x3DCCCCCD, which is exactly:
13421773 * 2^(-4 - 23) = 0.100000001490116119384765625
3e20 is closest represented by 0x61821AB1, which is exactly:
8526513 * 2^(68 - 23) = 300000006012263202816. We get 7 valid digits, this is normal and acceptable.

Also the fact that the float number is converted to double doesn't matter, double can hold every possible float without loss in precision.

I also tried the printf in the old crtdll.dll, same behavior.



--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

------------------------------

Message: 3
Date: Sat, 14 Jan 2017 15:02:46 +0100 (CET)
From: <tei.andu@xxxxxxxxxxxx>
Subject: [Mingw-users] msvcrt printf bug
To: <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <KaSHP9L--3-0@xxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"


Hello,
I encountered a loss of precision printing a float with C printf.
For values greater than or equal to 1.743397235870361328125 * 2 ^ 59 (0x5D5F27A4) the printed value is slightly wrong. The error increases with increasing input.
I attached a sample C file.
I tested against glibc 2.2.5 and against my own float to string.
The bug is in msvcrt. My msvcrt version is 7.0.7601.17744, crc32: DAB48B3A
mingw version: 4.0; gcc version: 5.3.0
Can anyone please confirm this?
I am sorry if this was posted before, I couldn't find anything.

--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pbug.c
Type: text/x-csrc
Size: 372 bytes
Desc: not available

------------------------------

Message: 4
Date: Sat, 14 Jan 2017 23:17:00 +0800
From: KHMan <keinhong@xxxxxxxxx>
Subject: Re: [Mingw-users] msvcrt printf bug
To: MinGW Users List <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <587A40EC.1030509@xxxxxxxxx>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 1/14/2017 10:02 PM, tei.andu@xxxxxxxxxxxx wrote:

Hello,
I encountered a loss of precision printing a float with C printf.
For values greater than or equal to 1.743397235870361328125 * 2 ^
59 (0x5D5F27A4) the printed value is slightly wrong. The error
increases with increasing input.

This is 19 digits:
1005000082153537536

The output is fine. When the 32 bit float is converted into 64
bits and then printed, it should be accurate up to about 17
digits. I would not trust anything beyond 17 digits with my
favorite teddy bear.

Why should one expect 19 digits of precision? Also, one should not
expect 8087's extended precision registers to be used anymore
unless it is explicitly required.

Do a round trip conversion, if you can't get back the number, then
maybe we have a problem. If you can get back the number, then
there is no problem, only a difference in expectations.
I attached a sample C file.
I tested against glibc 2.2.5 and against my own float to string.
The bug is in msvcrt. My msvcrt version is 7.0.7601.17744, crc32:
DAB48B3A
mingw version: 4.0; gcc version: 5.3.0
Can anyone please confirm this?
I am sorry if this was posted before, I couldn't find anything.


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia





Message: 7
Date: Sun, 15 Jan 2017 21:24:11 +0000
From: John Brown <johnbrown105@xxxxxxxxxxx>
Subject: Re: [Mingw-users] msvcrt printf bug
To: MinGW Users List <mingw-users@xxxxxxxxxxxxxxxxxxxxx>
Message-ID:
<DM3PR11MB0890CA081EA8F3F173B824E79E7A0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="iso-8859-1"

On Saturday, January 14, 2017 10:17 AM, KHMan wrote:
On 1/14/2017 10:02 PM, tei.andu@xxxxxxxxxxxx wrote:

Hello,
I encountered a loss of precision printing a float with C printf.
For values greater than or equal to 1.743397235870361328125 * 2 ^
59 (0x5D5F27A4) the printed value is slightly wrong. The error
increases with increasing input.
The output is fine. When the 32 bit float is converted into 64
bits and then printed, it should be accurate up to about 17
digits. I would not trust anything beyond 17 digits with my
favorite teddy bear.

Why should one expect 19 digits of precision? Also, one should not
expect 8087's extended precision registers to be used anymore
unless it is explicitly required.

You have skillfully avoided addressing the fact that it works as the
original poster expects with glibc 2.2.5 (tested on Linux / glibc 2.19).

Regards,
John Brown..


------------------------------

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
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