msvcrt printf bug

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

msvcrt printf bug

tei.andu
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: <[hidden email]>
Subject: [Mingw-users] msvcrt printf bug
To: <[hidden email]>
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: Re: [Mingw-users] msvcrt printf bug
To: MinGW Users List <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 1/14/2017 10:02 PM, [hidden email] 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 <[hidden email]>
Subject: Re: [Mingw-users] msvcrt printf bug
To: MinGW Users List <[hidden email]>
Message-ID:
<[hidden email]>

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, [hidden email] 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Peter Rockett
On 16/01/17 08:36, [hidden email] wrote:

> ...snip
>
> 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.

Sorry, I have followed this thread loosely but I am struggling to see
the practical relevance of this.

It is normal to perform floating-point operations using a couple of
extra digits (so-called guard digits) to boost accuracy. In my
experience, 80x87 co-processors often generate internal precisions of
19-20 digits. But if the number is stored back to an 8-byte memory slot,
it will perforce be rounded down to 15-16 digits.  In practice, most
meaningful floating point calculations will use standard memory slots to
save intermediate values. Therefore you should not believe anything
beyond 15-16 digits.  In light of this, I suspect somebody at Microsoft
has made the, arguably sensible, engineering decision not to fuss too
much about correctly handling the 18th and 19th digits. In practice,
these digits will usually be garbage!

Bottom line: Double-precision IEEE floating-point arithmetic is only
specified to be reliable up to 15-16 digits. You should not bet the farm
on the values of any 18th or 19th digits printf may produce. Ultimately,
at some level, floating point arithmetic is only ever approximate!

P.

>
> ...snip
>


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
In reply to this post by tei.andu
On 1/16/2017 4:36 PM, [hidden email] wrote:
> 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.

I think everyone on the list wants to help, including me.

There are now 4 persons who have responded to you, all are in
general agreement with how floats and doubles work. Isn't it time
you think for a bit that you may be on the wrong track? Now, if
you happen to be in high school or something, it is important that
you are missing a lot of stuff that you will be learning hopefully
in the future.

Let's just say that if you have done CompSci properly, it would be
quite impossible to make the kind of argument that you are doing now.

Sometimes when we think we are onto something, the thrill and
excitement can make us focus and keep focusing on a wrong
hypothesis. Nobody here seems to be in agreement with your
arguments. You should reevaluate.

> 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.

Sometimes smart people laser focus on the wrong things.

I will leave this discussion to other folks on the list.

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


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
In reply to this post by tei.andu
On 1/16/2017 4:36 PM, [hidden email] wrote:

> [snip snip snip]
> 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.

Oh, I should never have promised not to post again, heh.

The double precision number after conversion is the same. I
verified this on MinGW 5.3.0 and Linux Mint 17 (gcc 4.8). Try it
out yourself.

If you don't understand why none of us cared that printf printed
something slightly different, then your programming education has,
in fact, lacked something.

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


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe