msvcrt printf bug

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

msvcrt printf bug

tei.andu

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

pbug.c (389 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
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


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

John Brown
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

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/01/17 21:24, John Brown wrote:

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

And you've both dodged the utter irrelevance of the entire issue;
the OP noted that the claimed "bug" is in MSVCRT.DLL, so completely
beyond our power to do anything about it.  In reality, the issue
boils down to unrealistic expectations regarding _reproducible_
precision of floating point numbers: how can a representation with
only 53 bits _exactly_ record any more than 15 decimal digits?  If
differing output implementations produce differing rounding effects
beyond 15 significant decimal digits, that's hardly a bug; it is,
rather, a limitation of the underlying data representation.

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

iQIcBAEBAgAGBQJYe/CsAAoJEMCtNsY0flo/KwkQAI6Eh3pom7oW1OqM6E5CwqOT
h7ZToo+YlmmvqPITw0/bg+5bQ3tRbEJ8qXU+nk+maFV74SljAubc9rJGAzpLvlYH
WLi1VNwQYmN0bI8TNY1aHACyiwc/iscgYTtqgIiE4smW54GAfhYkCfOONXmfHzz2
yMtFIQqMxcp7jYnkd1OSvgFa7gPThZBm/50EgxoXrufnbLn4NefJpSzc7bFh5bsh
PHSmgHgZ11Dnt/xCZT19E8eTcv9NWG3RpqlQBKtxYSfHiBzw1QZzL++fbe9KRzN+
8nbvngRsk76tXSJr9GyzRQboqqE2sxea4OJqMfQStrrbcFSdvSQE7b51dzSGrlh9
yhV9sxzgld+8B3RFr/uVhyPNs4OjokS+WEqr5DE5zukaIuvn33B/VZJtp1oUTkpR
PLUK22XMuEVnvPZ37WVJzh3XQBXSM3r9pcrX8XDjnKjyM++u3LJZSzWJJ/wB8OlD
BcHH8m9nRWGhTlo+VWJ64VkHav6ZAgVp1I2okFkdt+yw6bxdqLSGh0XU+8OUd+DX
yBFspjgBiQtTpp1ict2+sABO9zS+vK0puXiYwdaQhJlgSYRhVVUlV/QK/JMFJSVb
9EKRcFaPynkEdGN9WHtWwSiLxPDfYh1MPemwdwF98Ve4SP4DBDzpUd/C5QJopB3R
M7hgyP9vkicmw3yKHhvm
=QCjg
-----END PGP SIGNATURE-----

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

John Brown
On  Sunday, January 15, 2017 4:59 PM, Keith Marshall wrote:
> On 15/01/17 21:24, John Brown wrote:
>> 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).

> And you've both dodged the utter irrelevance of the entire issue;
>>  the OP noted that the claimed "bug" is in MSVCRT.DLL, so completely
> beyond our power to do anything about it.  In reality, the issue
> boils down to unrealistic expectations regarding _reproducible_
> precision of floating point numbers: how can a representation with
> only 53 bits _exactly_ record any more than 15 decimal digits?  If
> differing output implementations produce differing rounding effects
> beyond 15 significant decimal digits, that's hardly a bug; it is,
> rather, a limitation of the underlying data representation.

Yes, you are right on all counts.

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

KHMan
On 1/16/2017 8:56 AM, John Brown wrote:
> On  Sunday, January 15, 2017 4:59 PM, Keith Marshall wrote:
>> On 15/01/17 21:24, John Brown wrote:
>>> 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).

It's not a perfect discourse that I wrote, so sorry. I was
shooting the breeze because I was curious to see where it went...
:-p I promise I will (try) not post anymore to this thread after
the following.

I do not think there are canonical conversion algorithms that must
always be upheld, so I did not have an expectation that glibc must
be canonical.

The glibc result is one data point, msvcrt is also one data point.
He claims to have his own float to string, but knowing digits of
precision limitations and the platform difference, why is he so
strident in knocking msvcrt? Curious. I won't score that, so we
are left with two data points running what are probably
non-identical algorithms.

>> And you've both dodged the utter irrelevance of the entire issue;
>>>   the OP noted that the claimed "bug" is in MSVCRT.DLL, so completely
>> beyond our power to do anything about it.  In reality, the issue
>> boils down to unrealistic expectations regarding _reproducible_
>> precision of floating point numbers: how can a representation with
>> only 53 bits _exactly_ record any more than 15 decimal digits?  If
>> differing output implementations produce differing rounding effects
>> beyond 15 significant decimal digits, that's hardly a bug; it is,
>> rather, a limitation of the underlying data representation.
>
> Yes, you are right on all counts.

To me the "beyond our power" thing is obvious. I was more
interested in what the OP was trying to do. Hence, shooting the
breeze...

It's unclear why he wants to use 19 digit precision test data on
32-bit float to string. I'm curious, but we may never know. For
that expectation we pretty much need everyone to be using the same
conversion algorithm. For perfect round trip conversion, via
Wikipedia (*cough*) according to Kahan: 9 digits for floats, 17
digits for doubles. Useful digits in normal use is less, as what
Keith has said above.

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

Earnie Boyd
In reply to this post by John Brown
On 1/15/2017 4:24 PM, John Brown wrote:
>
> 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).
>

Maybe providing a pristine patch could help.  You also make comparisons
between apples and oranges, the two are just not the same; just like
Linux and its C runtime is not the same as the Windows C runtime.  We
have in the past created workarounds for what appeared to be
deficiencies in the Microsoft C runtime.

--
Earnie

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/01/17 16:51, Earnie wrote:

> On 1/15/2017 4:24 PM, John Brown wrote:
>>
>> 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).
>>
>
> Maybe providing a pristine patch could help.  You also make comparisons
> between apples and oranges, the two are just not the same; just like
> Linux and its C runtime is not the same as the Windows C runtime.  We
> have in the past created workarounds for what appeared to be
> deficiencies in the Microsoft C runtime.

And, in this case, we _already_ have a perfectly viable alternative
to the entire family of MSVCRT.DLL printf() functions; (enable it
by defining _XOPEN_SOURCE to any non-zero value, prior to including
_any_ header file ... see <_mingw.h> for the specifically pertinent
values).  It uses David M. Gay's gdtoa floating point formatting
engine, (which, AFAIK is the same as used by glibc, so I'd expect
consistent output).

Regardless, it is a bug to emit more significant digits than the
underlying data format is capable of representing ... a bug by
which both glibc and our implementation are, sadly, afflicted;
that the OP attempts to attribute any significance whatsoever to
those superfluous digits is indicative of an all too common gap
in knowledge ... garbage is garbage, whatever form it may take.

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

iQIcBAEBAgAGBQJYfSpvAAoJEMCtNsY0flo/O8UP/2QdQdKWbWzAPXNlbimZj112
ogyPa1dsibCUDuu/YV2srkyXB6hMfhKl1yvNUz/D4Tb9KYFAUF0kpY5nKQ5plH5F
mow7Rov0vrAgSy4V2nnPV0NK9SnTRLgsdqBXUFDfBTKNxRpNkK/iBaSjmCCj3sVV
ViteHu9An70wzWH6d4Rh+fC8pOomX2/E2ICHd6CWj/C+wozrJjn+zxX1anTNdX/n
Ws5CTW/Ofqxysw5644m6UB0w8kcW3+1PljsJAvemZtKJHNet770qL9OOkTg3l12S
5ExRym/aqRsuFN2tYp6bheaprSF7r2Z+DhLkWoAVxpQr/0y0X3C/R1SzYOg5XjFK
zk82UhaynUlXZmTEB/qcs6mF9vMvWxXJ8LShoUVrhGkOnWaGcRZZah+6hNRUC4Ek
lyfWGZrM2amvFrkZFBrZtEThum1lLGC9mNQvzE8s/K+0Jl8SrjRjbaDuEBsg9cd6
q8lJoVa9IFOt59G6mXLYLar3I81irvmOs+r1tIvoGYS5XAoRpGA8nv7iX7tyWJY8
CQrMHxqlaOwyxzBf7g0Rp//QpDvSASPp/cpynDrPAU3uD8pLwVQpfirtedEb5eIm
7XyXMNRvKHR35xmCKIxpF6+MCLAnXfkConS3Bp8/mHCvZn4+6/W4rRR2zr3TA2W+
bERci/93lta2d3u7zG3N
=3B6Y
-----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
[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

tei.andu
In reply to this post by tei.andu

Hello all,
Thank you for your kind advice and your time. I also did some more searching around.
I understand that there is no practicality to getting the exact value of a float, only enough precision
that can give a back conversion (decimal string -> float) with the same value is required.
However, my examples are correct. You can verify them with a calculator with enough precision or a bignum library (or glibc).
If you google 'exact value of a float' you will even find code samples that will do that. glibc also does it. The digits are not garbage, they are the result of a complete conversion.
See: http://stackoverflow.com/questions/3215235/how-do-you-print-the-exact-value-of-a-floating-point-number
There is no rounding required if we want this exact value, no floating point operations required,
no 8087, no long double. Just 32 bit float -> decimal string.
There is rounding on the reverse operation (decimal string -> float) of course.

From here:
https://randomascii.wordpress.com/2013/02/07/float-precision-revisited-nine-digit-float-portability
"Printing the exact value of a 32-bit float can take up to 112 decimal digits of mantissa"

I put my code on pastebin: http://pastebin.com/svxrefSy
-it prints the exact value of a float representation
-handles denormals
-no floating point operations
-can be easily extended for double, long double etc.
-small and succinct
Working on this is how I found the msvcrt printf mismatch.
How it works: the 24 bit (23 for denormals) mantissa is transposed into an 160.160 bit fixed precision representation.
Then, the whole part and fractional part are processed separately.
For the whole part the digits are extracted by long division and modulo by 10 and for the fractional part they are extracted by multiplication by 10. I made this to run on a cortex-m4 (armv7 microcontroller). I tested it on x86 and x86_64.

Thank you Keith for _XOPEN_SOURCE macro. I will try it.
Thank you all again and I am sorry if I upset anyone.

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

17. Jan 2017 17:39 by [hidden email]:


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

Message: 1
Date: Mon, 16 Jan 2017 10:09:24 +0000
From: Peter Rockett <[hidden email]>
Subject: Re: [Mingw-users] msvcrt printf bug
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=windows-1252; format=flowed

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




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

Message: 2
Date: Mon, 16 Jan 2017 23:22:21 +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/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




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

Message: 3
Date: Mon, 16 Jan 2017 23:45:32 +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/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




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

Message: 4
Date: Mon, 16 Jan 2017 11:51:46 -0500
From: Earnie <[hidden email]>
Subject: Re: [Mingw-users] msvcrt printf bug
To: [hidden email]
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset=windows-1252

On 1/15/2017 4:24 PM, John Brown wrote:

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

Maybe providing a pristine patch could help. You also make comparisons
between apples and oranges, the two are just not the same; just like
Linux and its C runtime is not the same as the Windows C runtime. We
have in the past created workarounds for what appeared to be
deficiencies in the Microsoft C runtime.

--
Earnie



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

Message: 5
Date: Mon, 16 Jan 2017 20:17:51 +0000
From: Keith Marshall <[hidden email]>
Subject: Re: [Mingw-users] msvcrt printf bug
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/01/17 16:51, Earnie wrote:
On 1/15/2017 4:24 PM, John Brown wrote:

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

Maybe providing a pristine patch could help. You also make comparisons
between apples and oranges, the two are just not the same; just like
Linux and its C runtime is not the same as the Windows C runtime. We
have in the past created workarounds for what appeared to be
deficiencies in the Microsoft C runtime.

And, in this case, we _already_ have a perfectly viable alternative
to the entire family of MSVCRT.DLL printf() functions; (enable it
by defining _XOPEN_SOURCE to any non-zero value, prior to including
_any_ header file ... see <_mingw.h> for the specifically pertinent
values). It uses David M. Gay's gdtoa floating point formatting
engine, (which, AFAIK is the same as used by glibc, so I'd expect
consistent output).

Regardless, it is a bug to emit more significant digits than the
underlying data format is capable of representing ... a bug by
which both glibc and our implementation are, sadly, afflicted;
that the OP attempts to attribute any significance whatsoever to
those superfluous digits is indicative of an all too common gap
in knowledge ... garbage is garbage, whatever form it may take.

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

iQIcBAEBAgAGBQJYfSpvAAoJEMCtNsY0flo/O8UP/2QdQdKWbWzAPXNlbimZj112
ogyPa1dsibCUDuu/YV2srkyXB6hMfhKl1yvNUz/D4Tb9KYFAUF0kpY5nKQ5plH5F
mow7Rov0vrAgSy4V2nnPV0NK9SnTRLgsdqBXUFDfBTKNxRpNkK/iBaSjmCCj3sVV
ViteHu9An70wzWH6d4Rh+fC8pOomX2/E2ICHd6CWj/C+wozrJjn+zxX1anTNdX/n
Ws5CTW/Ofqxysw5644m6UB0w8kcW3+1PljsJAvemZtKJHNet770qL9OOkTg3l12S
5ExRym/aqRsuFN2tYp6bheaprSF7r2Z+DhLkWoAVxpQr/0y0X3C/R1SzYOg5XjFK
zk82UhaynUlXZmTEB/qcs6mF9vMvWxXJ8LShoUVrhGkOnWaGcRZZah+6hNRUC4Ek
lyfWGZrM2amvFrkZFBrZtEThum1lLGC9mNQvzE8s/K+0Jl8SrjRjbaDuEBsg9cd6
q8lJoVa9IFOt59G6mXLYLar3I81irvmOs+r1tIvoGYS5XAoRpGA8nv7iX7tyWJY8
CQrMHxqlaOwyxzBf7g0Rp//QpDvSASPp/cpynDrPAU3uD8pLwVQpfirtedEb5eIm
7XyXMNRvKHR35xmCKIxpF6+MCLAnXfkConS3Bp8/mHCvZn4+6/W4rRR2zr3TA2W+
bERci/93lta2d3u7zG3N
=3B6Y
-----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
[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

tei.andu
In reply to this post by tei.andu
I messed up the pastebin. Forgot float union. Fixed:
http://pastebin.com/zeLeD021
--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

18. Jan 2017 00:28 by [hidden email]:

I put my code on pastebin: http://pastebin.com/svxrefSy


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Emanuel Falkenauer
Hi Tei Andu(?),

I've been following this thread from afar but with a huge interest - and as far as I'm concerned, you certainly did not offend anybody!

For all sorts of reasons, we develop and debug our algorithms in Embarcadero RAD Studio (a.k.a. "Borland") but, being in HPC, execution speed is paramount for our products and MinGW has proved unbeatable there (excellent work, people!!), so it's MinGW builds (both 32- and 64-bit) we ship - in short, we build our algorithms in two different compilers.

Now to debug in Embarcadero a problem found in a MinGW build, we must be sure that the two versions behave exactly the same, and it's anyway a good QC practice to make sure that that is indeed the case. In order to do that, we have developed a whole tracing system where one version writes the details of its progress into a log and the other version then reads it to spot any differences in behavior. The system already saved us years in debugging... but floats have always been a problem: Embarcadero and MinGW don't (s)print(f) them the same! The last digit in the log is different so often, that many times the logging becomes largely useless: millions of BOGUS differences show up.
Usually we resign ourselves to use sprintf("%.4f",...) or such, and skip by hand what are clearly bogus "differences" remaining - but that always leaves the uncertainty that the differences COULD actually be real, i.e. that the exact float values are really different in the two builds.

So as you may guess, I grabbed your pastebin the minute you posted it, adapted it for our purposes (mainly to print into a char[]) and tested it immediately (in 64-bit MinGW and 32-bit Embarcadero so far) - and my conclusion is that your put_f32(float f32) works EXACTLY AS ADVERTISED: both our builds now generate exactly the same logs.

This is really INVALUABLE for us, as it will save us years of debugging headaches. So I would not only like to THANK you a lot, but also give you credit in our adapted sources - how would you like us to refer to you as the original author?

Many thanks again,

Emanuel


On 18-Jan-17 00:44, [hidden email] wrote:
I messed up the pastebin. Forgot float union. Fixed:
http://pastebin.com/zeLeD021
--
Securely sent with Tutanota. Claim your encrypted mailbox today!
https://tutanota.com

18. Jan 2017 00:28 by [hidden email]:

I put my code on pastebin: http://pastebin.com/svxrefSy



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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
In reply to this post by tei.andu
On 1/18/2017 6:27 AM, [hidden email] wrote:

> Hello all,
> Thank you for your kind advice and your time. I also did some more
> searching around.
> I understand that there is no practicality to getting the exact
> value of a float, only enough precision
> that can give a back conversion (decimal string -> float) with the
> same value is required.
> However, my examples are correct. You can verify them with a
> calculator with enough precision or a bignum library (or glibc).
> If you google 'exact value of a float' you will even find code
> samples that will do that. glibc also does it. The digits are not
> garbage, they are the result of a complete conversion.
[snip snip]

Ultimately, you bear the risks. If you are still a student, be
humble, study more. Think before you cry wolf.

> http://stackoverflow.com/questions/3215235/how-do-you-print-the-exact-value-of-a-floating-point-number
> There is no rounding required if we want this exact value, no
> floating point operations required,
[snip snip]

The blog post states there were ZERO errors doing round trips. No
errors. What bug?

Google may have smart people laser focused on the wrong things
too. Do not trust too easily.

So he wants to find perfection in ASCII displays of floats.
Yawn... Google and Google employees have money, leave them to play...

Once you do calculations in floating point, whatever 0.5ULP does
not matter anymore, error accumulates, the perfect ASCII display
is an exercise in perfectionism. Go and have fun with the
so-called perfect conversion code, however dubious its real-world
value is, but it's foolish to tell the world there are bugs here
and there. Think before you act, man.

IIRC you should not consider your kind of perfect ASCII conversion
to be of any real importance in real world settings. There was
once an article -- a grad student doing aerospace, his program was
so sensitive to tiny pertubations that he only got useful *cough*
'results' on a particular CPU. Other CPUs gave wildly different
results. After graduating, he questioned whether the program which
was supposed to produce consistently reproducible results was
actually useful if it amplified tiny variations in calculations
and made a molehill out of them. Was his research results good
valuable simulation or a molehill? Hmmm...

Error accumulates in real world calculations. Folks who enjoy
their perfect ASCII conversions should remain in their niche.

[snip snip]

--
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
In reply to this post by tei.andu
On 1/18/2017 6:27 AM, [hidden email] wrote:
> [snip snip snip]
> See:
> http://stackoverflow.com/questions/3215235/how-do-you-print-the-exact-value-of-a-floating-point-number

The author stated:
   "the number required to “exactly print” its value"

This is flat out a monkey wrench that destroys the real-world
concept of a floating-point value.

He assumes pristine, exact values. This notion of pristine, exact
values disappears when you start doing calculations.

It's a magic kingdom, constrained to assumptions.

As for Emanuel's posting, I find it good for a chuckle. So the
binary representations were fine, and they spent years moping
about with ULP issues in ASCII representations. Look, some of us
would have fixed that in an afternoon. Enough said.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Emanuel Falkenauer
In reply to this post by KHMan
Hi KHMan,

Sorry, but you're WRONG: Tei's code is actually INVALUABLE to us (and
certainly not "Yawn"!!) - you'd be better off not berating him (or her?)
to be "a student" (why would "a student" be worse than you, btw?!) and
THINK about what (s)he has to say before making clearly wrong conclusions!

Emanuel

On 18-Jan-17 03:20, KHMan wrote:

> On 1/18/2017 6:27 AM, [hidden email] wrote:
>> Hello all,
>> Thank you for your kind advice and your time. I also did some more
>> searching around.
>> I understand that there is no practicality to getting the exact
>> value of a float, only enough precision
>> that can give a back conversion (decimal string -> float) with the
>> same value is required.
>> However, my examples are correct. You can verify them with a
>> calculator with enough precision or a bignum library (or glibc).
>> If you google 'exact value of a float' you will even find code
>> samples that will do that. glibc also does it. The digits are not
>> garbage, they are the result of a complete conversion.
> [snip snip]
>
> Ultimately, you bear the risks. If you are still a student, be
> humble, study more. Think before you cry wolf.
>
>> http://stackoverflow.com/questions/3215235/how-do-you-print-the-exact-value-of-a-floating-point-number
>> There is no rounding required if we want this exact value, no
>> floating point operations required,
> [snip snip]
>
> The blog post states there were ZERO errors doing round trips. No
> errors. What bug?
>
> Google may have smart people laser focused on the wrong things
> too. Do not trust too easily.
>
> So he wants to find perfection in ASCII displays of floats.
> Yawn... Google and Google employees have money, leave them to play...
>
> Once you do calculations in floating point, whatever 0.5ULP does
> not matter anymore, error accumulates, the perfect ASCII display
> is an exercise in perfectionism. Go and have fun with the
> so-called perfect conversion code, however dubious its real-world
> value is, but it's foolish to tell the world there are bugs here
> and there. Think before you act, man.
>
> IIRC you should not consider your kind of perfect ASCII conversion
> to be of any real importance in real world settings. There was
> once an article -- a grad student doing aerospace, his program was
> so sensitive to tiny pertubations that he only got useful *cough*
> 'results' on a particular CPU. Other CPUs gave wildly different
> results. After graduating, he questioned whether the program which
> was supposed to produce consistently reproducible results was
> actually useful if it amplified tiny variations in calculations
> and made a molehill out of them. Was his research results good
> valuable simulation or a molehill? Hmmm...
>
> Error accumulates in real world calculations. Folks who enjoy
> their perfect ASCII conversions should remain in their niche.
>
> [snip snip]
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Emanuel Falkenauer
And btw: when will YOU become "humble" and start to "study more"? ;-)

On 18-Jan-17 03:44, Emanuel Falkenauer wrote:

> Hi KHMan,
>
> Sorry, but you're WRONG: Tei's code is actually INVALUABLE to us (and
> certainly not "Yawn"!!) - you'd be better off not berating him (or
> her?) to be "a student" (why would "a student" be worse than you,
> btw?!) and THINK about what (s)he has to say before making clearly
> wrong conclusions!
>
> Emanuel
>
> On 18-Jan-17 03:20, KHMan wrote:
>> On 1/18/2017 6:27 AM, [hidden email] wrote:
>>> Hello all,
>>> Thank you for your kind advice and your time. I also did some more
>>> searching around.
>>> I understand that there is no practicality to getting the exact
>>> value of a float, only enough precision
>>> that can give a back conversion (decimal string -> float) with the
>>> same value is required.
>>> However, my examples are correct. You can verify them with a
>>> calculator with enough precision or a bignum library (or glibc).
>>> If you google 'exact value of a float' you will even find code
>>> samples that will do that. glibc also does it. The digits are not
>>> garbage, they are the result of a complete conversion.
>> [snip snip]
>>
>> Ultimately, you bear the risks. If you are still a student, be
>> humble, study more. Think before you cry wolf.
>>
>>> http://stackoverflow.com/questions/3215235/how-do-you-print-the-exact-value-of-a-floating-point-number 
>>>
>>> There is no rounding required if we want this exact value, no
>>> floating point operations required,
>> [snip snip]
>>
>> The blog post states there were ZERO errors doing round trips. No
>> errors. What bug?
>>
>> Google may have smart people laser focused on the wrong things
>> too. Do not trust too easily.
>>
>> So he wants to find perfection in ASCII displays of floats.
>> Yawn... Google and Google employees have money, leave them to play...
>>
>> Once you do calculations in floating point, whatever 0.5ULP does
>> not matter anymore, error accumulates, the perfect ASCII display
>> is an exercise in perfectionism. Go and have fun with the
>> so-called perfect conversion code, however dubious its real-world
>> value is, but it's foolish to tell the world there are bugs here
>> and there. Think before you act, man.
>>
>> IIRC you should not consider your kind of perfect ASCII conversion
>> to be of any real importance in real world settings. There was
>> once an article -- a grad student doing aerospace, his program was
>> so sensitive to tiny pertubations that he only got useful *cough*
>> 'results' on a particular CPU. Other CPUs gave wildly different
>> results. After graduating, he questioned whether the program which
>> was supposed to produce consistently reproducible results was
>> actually useful if it amplified tiny variations in calculations
>> and made a molehill out of them. Was his research results good
>> valuable simulation or a molehill? Hmmm...
>>
>> Error accumulates in real world calculations. Folks who enjoy
>> their perfect ASCII conversions should remain in their niche.
>>
>> [snip snip]
>>
>
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
In reply to this post by Emanuel Falkenauer
On 1/18/2017 10:44 AM, Emanuel Falkenauer wrote:
> Hi KHMan,
>
> Sorry, but you're WRONG: Tei's code is actually INVALUABLE to us (and
> certainly not "Yawn"!!) - you'd be better off not berating him (or her?)
> to be "a student" (why would "a student" be worse than you, btw?!) and
> THINK about what (s)he has to say before making clearly wrong conclusions!

Oh, so sorry for making you angry. I apologize, I apologize. Cheer
up :-)

I have always prefaced the gently-prodding student thing with
"If". Check back if you think otherwise. I presumed Tei did not
want to divulge any information of that sort. I think "berating"
is a wrong characterization, now it's you who is doing that to me.

Bruce Dawson's work is interesting, but some of the talk may be
misleading to some folks. So he wants consistent ASCII
representations, good for multi-platform work. float was fine for
round trip, at the end he stated that VC++ double conversion may
have issues. Interesting, but too many uses of 'exact' that makes
me cringe.

I thought everyone knew not to rely on exact ASCII representations
across everywhere. Isn't it obvious from an engineering
standpoint? Floating point is a lot about managing imperfection...

--
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

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

As I said: issue settled, no hard feelings left. Have a great day!

Emanuel

On 18-Jan-17 04:04, KHMan wrote:

> On 1/18/2017 10:44 AM, Emanuel Falkenauer wrote:
>> Hi KHMan,
>>
>> Sorry, but you're WRONG: Tei's code is actually INVALUABLE to us (and
>> certainly not "Yawn"!!) - you'd be better off not berating him (or her?)
>> to be "a student" (why would "a student" be worse than you, btw?!) and
>> THINK about what (s)he has to say before making clearly wrong conclusions!
> Oh, so sorry for making you angry. I apologize, I apologize. Cheer
> up :-)
>
> I have always prefaced the gently-prodding student thing with
> "If". Check back if you think otherwise. I presumed Tei did not
> want to divulge any information of that sort. I think "berating"
> is a wrong characterization, now it's you who is doing that to me.
>
> Bruce Dawson's work is interesting, but some of the talk may be
> misleading to some folks. So he wants consistent ASCII
> representations, good for multi-platform work. float was fine for
> round trip, at the end he stated that VC++ double conversion may
> have issues. Interesting, but too many uses of 'exact' that makes
> me cringe.
>
> I thought everyone knew not to rely on exact ASCII representations
> across everywhere. Isn't it obvious from an engineering
> standpoint? Floating point is a lot about managing imperfection...
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

KHMan
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!

--
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
Reply | Threaded
Open this post in threaded view
|

Re: msvcrt printf bug

Emanuel Falkenauer
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!

Emanuel


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

Emanuel Falkenauer
Corrections:

> *(s)*he solved it. *(S)*he sure may not have been the first, but *(s)*he was willing to
> share his*/her* code here, and I believe *(s)*he deserves thanks for that.

I may be a man... but I love girls and wish them all the appreciation
they deserve!  ;-)

On 18-Jan-17 06:37, Emanuel Falkenauer wrote:

> 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!
>
> Emanuel
>
>
> 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
> [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
>


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