Quantcast

msvcrt printf bug

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

[OT] comparing floating point results of different compilers (was: msvcrt printf bug)

Alberto Luaces
Emanuel Falkenauer writes:

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

Honest question: how can you compare the outputs of a program compiled
by two different compilers?  How can you make sure that all the
computations are carried in the same order?  That cannot be done even
when using different optimization flags on the same compiler.

Are you by chance comparing the result of an iterative process that
should converge to a final value?

--
Alberto


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: [OT] comparing floating point results of different compilers

Tuomo Latto-3
On 18.01.2017 10:48, Alberto Luaces wrote:

> Emanuel Falkenauer writes:
>
>> 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.
>
> Honest question: how can you compare the outputs of a program compiled
> by two different compilers?  How can you make sure that all the
> computations are carried in the same order?  That cannot be done even
> when using different optimization flags on the same compiler.

But the fact that programs produced by different compilers work the same
way, produce the same effects and, in general, even work at all,
proves that they are the same to the relevant degree. Remember, we are
not talking about the exact choice or ordering of CPU instructions
for a single task, but are, in fact, talking about the results of those
instructions, the completion of that task.
Logging isn't a separate functionality but integrated to the program
and thus taken into account in the analysis of the data flow.
If a compiler optimizes results away or compromises their integrity
or precision without being asked to, it is faulty.

The way a compiler knows whether a value in a variable is a "result"
or not is by looking if (and how) the data is being used - in this case
probably by if it is taken outside the FPU (memory, GP registers, etc.).
If it is not, it's an intermediate value that can be discarded once
not needed, optimized away, or, if aggressively optimized, replaced
by a more efficient way. On the other hand if it is used, then it is
a result required in the program that the compiler aims to create,
a target to satisfy, even if it optimizes how it reaches that target.

> Are you by chance comparing the result of an iterative process that
> should converge to a final value?

The ftoa calculation is such a process that could be useful to have it
provide the same answers when compared across compilers, like for Emanuel.
However, the input float values for the process should still be equal
up to some precision for all environments, which is what he is trying to
verify by comparing the logs.


--
Tuomo

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

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


Hi all,
Emanuel, thank you very much for stepping in. I am extremely happy that you found my code useful.
For me it's the first time that happens. You made the trouble of posting this issue worthwhile for me.
You can use the code however you like but beware I haven't tested for all possible inputs, as I need something to test against. Even the glibc printf starts dropping significant digits for denormals.
If I manage to test completely, I will notify you on your email.
My name is 'Alexandru', 'Andu' is a shorthand. No need to give me credit.
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. 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.



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

18. Jan 2017 05:39 by [hidden email]:


Message: 1
Date: Wed, 18 Jan 2017 10:34:19 +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/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




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

Message: 2
Date: Wed, 18 Jan 2017 03:44:28 +0100
From: Emanuel Falkenauer <[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

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]




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

Message: 3
Date: Wed, 18 Jan 2017 03:48:49 +0100
From: Emanuel Falkenauer <[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

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]





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

Message: 4
Date: Wed, 18 Jan 2017 11:04:47 +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/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




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

Message: 5
Date: Wed, 18 Jan 2017 04:39:13 +0100
From: Emanuel Falkenauer <[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

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]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users


End of MinGW-users Digest, Vol 128, Issue 9
*******************************************

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Earnie Boyd
In reply to this post by KHMan
On 1/17/2017 10:04 PM, KHMan wrote:
> Floating point is a lot about managing imperfection...
>

Has been since the dawning of math and doing math with computers is best
left to integers.  If possible multiply input by the expected precision,
100, 1000, etc and store as an integer.  Divide by the precision
multiplier before presenting the result to the use.  It's what I had to
do 36 years ago when I was working with 16 bit computers and if I need
to present dollars and cents still do today.

--
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

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

There is a bug in my float to string that I linked earlier. Do not use it.
It triggers with 0x106B7ADE. Haven't found the cause yet, I suspect the lack of carry propagation.
I tested Keith's _XOPEN_SOURCE macro solution. Works perfectly. All digits are printed.

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


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Keith Marshall-3
In reply to this post by tei.andu
-----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, [hidden email] 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
[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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Emanuel Falkenauer
Keith,

With all due respect, I think you never got what this is about. It may
seem strange, but it really doesn't take a genius to know that floats
have finite precision - and guess what: nobody ever argued otherwise!
All I would like to have is the same (i.e. binary identical) floats
printed the same (i.e. char identical) way across compilers. Yes yes
yes, I KNOW the floats are imprecise, but I happily live with that
(since their precision is sufficient for my particular purpose), as long
as they are imprecise the same way in both builds of my algorithms - and
it actually IS the case. When it's not, it's always because of a bug
somewhere.
The only problem was checking that automatically, due to the fact that
the two compilers print the same values differently. That is now largely
solved, and I can move on to other things.

All the best,

Emanuel

P.S. What about starting some new threads: qsort doesn't behave the same
across compilers wrt equal values either, and neither do the random
generators.  ;-)

On 18-Jan-17 22:39, Keith Marshall wrote:

> -----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, [hidden email] 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
> [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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: msvcrt printf bug

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

On 18/01/17 22:18, Emanuel Falkenauer wrote:
> With all due respect, I think you never got what this is about.

Yes, I did.  I fully understood that your holy grail was
consistency, even if that equates to "consistently imprecise",
or "consistently inaccurate".  That's absolutely fine, but, once
you go beyond the limit of representable precision inherent in
the underlying data type, you become dependent on fiction; the
only way to guarantee consistency in that fiction is to employ
identically the same algorithm to produce it ... and the further
you go beyond that limit of precision, the less likely it may
become that such consistency is preserved -- realistically, you
should never look more than two digits beyond floor(N*log10(2))
in any case.

So, if you want consistency in printf()'s imprecision, then you
should be using _our_ printf(), (which uses, AFAIK, identically
the same algorithm as both cygwin and GNU's glibc); Microsoft
use their own algorithm, which is thus most unlikely to yield
the same output, _beyond the limit of representable precision_.

My point was that there is a significant volume of ill-informed
nonsense pervading the internet, which encourages the naive, and
the ignorant, to believe that float, double, and long double can
accurately represent many more digits of precision than the
number of available bits in the underlying data type can
physically sustain; I get utterly fed up with dismissing "bug"
reports to the effect that printf( "%.20e", foo ) prints the wrong
value in the least significant digits, when "%.15e" is the most
that can dependably produce _accurate_ results; (the additional
five digits, requested by "%.20e", are speculative).

- --
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/Q6AAoJEMCtNsY0flo/6foQAIKcKS3V22Zh4wGNJPnBzRcV
0WmiLpoDevTjAZrOxrKa0SC8Qffk0B0jqxAlYWYt7b5S6LkgfdPq6UBv03MVPZwE
JLeG7KZT2P3vYCQJJ4nDrv29xaDVHC/8atzBLSlP/AXJ+7ulT5aFskLT1tnUtVEd
5ArYipxHj1luzxtd71aO/VKN1LRPuB8wZf5To3wz8SiXlM3ICTB0OTU7fmTmyf55
Heay0he/uLA/MU5Qn7kQTK05wIkJLEHKkdgJV/rlgNBbmvlRjF/ZaYGgV9nI5zxK
3Oy/SbeuV97N89EtuPumOrCCF1jP3DsJ8Oc4GweDZzzXCPOKiNYHMOoKlSVcrwYG
0Y7jNq++5xVam7RNqsJVLPc6VUX3EkMbNuYLBy0dVzabJLwvD48e9kFU4AKj6Kej
FygmAWkbPNpGr9m5w4hx8gD+EgbfBzFccT61ERf1yX4RJ3spTkxBtfQJj+3Zsa8v
zK/5N42A752Gq7POdZ8ZwQ1rmNmwo7rP+IV/bI1lrf0XOy7bN6d9/z0RzcOQ/s4O
oCiCnUahq8uvtEhHLX6xO7IdV0wwGAA1m90p9ERcIeq7H6Q+xi31Apo5wfju2EEG
H3bAOcDNvT4ff+Lv7/8BDOrOOFpkSPy6LR3MHtv+8kUaPOgORRSOxz9GPr/aAuXp
gcuj1lBWXOFUycv41PJC
=/hO4
-----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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Emanuel Falkenauer

> Yes, I did.  I fully understood that your holy grail was
> consistency, even if that equates to "consistently imprecise",
> or "consistently inaccurate".

Correct.

> That's absolutely fine, but, once
> you go beyond the limit of representable precision inherent in
> the underlying data type, you become dependent on fiction; the
> only way to guarantee consistency in that fiction is to employ
> identically the same algorithm to produce it ... and the further
> you go beyond that limit of precision, the less likely it may
> become that such consistency is preserved -- realistically, you
> should never look more than two digits beyond floor(N*log10(2))
> in any case.

Incorrect: I never said I would like to "see" beyond the precision limit!

Trouble is, it's NOT trivial to stop before that limit with printf.
Sure, I could print %.2f when the two digits are the only valid ones,
but that would prevent me from correctly printing e.g. 0.00001234 so
that it would show differently from 0.00001236 (even though both only
have four significant digits).
I simply didn't find a reliable way of printing those floats when they
vary by orders of magnitude.

> So, if you want consistency in printf()'s imprecision, then you
> should be using _our_ printf(), (which uses, AFAIK, identically
> the same algorithm as both cygwin and GNU's glibc); Microsoft
> use their own algorithm, which is thus most unlikely to yield
> the same output, _beyond the limit of representable precision_.

I would LOVE to use _your_ printf... but remember: the whole story is
about comparing with Borland builds, where it's not available.

> My point was that there is a significant volume of ill-informed
> nonsense pervading the internet, which encourages the naive, and
> the ignorant, to believe that float, double, and long double can
> accurately represent many more digits of precision than the
> number of available bits in the underlying data type can
> physically sustain; I get utterly fed up with dismissing "bug"
> reports to the effect that printf( "%.20e", foo ) prints the wrong
> value in the least significant digits, when "%.15e" is the most
> that can dependably produce _accurate_ results; (the additional
> five digits, requested by "%.20e", are speculative).

Once again, this was always understood - at the very least I never
argued otherwise.

Best,

Emanuel

> - --
> Regards,
> Keith.
>

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

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

On 18/01/17 23:34, Emanuel Falkenauer wrote:
> Trouble is, it's NOT trivial to stop before that limit with printf.
> Sure, I could print %.2f when the two digits are the only valid ones,
>  but that would prevent me from correctly printing e.g. 0.00001234 so
>  that it would show differently from 0.00001236 (even though both
> only have four significant digits). I simply didn't find a reliable
> way of printing those floats when they vary by orders of magnitude.

"%.2f" doesn't specify significant digits -- it specifies digits
after the radix point.  If you want to see, and compare, just so
many significant digits, you would surely be better off using
"%.2e", (so you don't get the leading insignificant zeros).

One other potential issue, which I neglected to mention: when you
perform floating point calculations you may suffer rounding, or
even cancellation effects, all of which conspire to make even less
than the absolute maximum representable precision available.  This
may be further compounded by differing FPU configuration between
implementations -- e.g. it is my understanding that Microsoft
configure the FPU to operate in 8-byte register mode, whereas
GCC uses full 10-byte capability.  Such configuration differences
could lead to rounding differences, even within the available
53-binary/15.955-decimal digit precision limit.

> I would LOVE to use _your_ printf... but remember: the whole story is
> about comparing with Borland builds, where it's not available.

Well, you are always likely to be on a hiding to nothing, when
you compare apples with oranges, and expect identity -- in this
case, how can you possibly expect consistency between Borland's
proprietary (likely undisclosed) algorithm and A. N. Other's?

If you want guaranteed consistency, you'd better use identically
the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
alternative?

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

iQIcBAEBAgAGBQJYgAoSAAoJEMCtNsY0flo/DnYP/jtDytQ4YNJjdaWNFix69qT7
weg8Y/61UjLaxiJag4LY2CR9n4X8lAxQJtwUT1gS7m3RM8O48Vhgxma2I1xXc0p3
L2tieGI2Mt1zLwnjJx6XJIFNwSUj0VhcSdYnhlWF6rROXqOqOM9s/XTH2gn3EvBU
mXccqebDzK7yR4anRw2qhUj+ojAjYgp1s54W79OmHfHRR3tRJ0F3mmDtBfLUFCrk
uL9maVxdcNOuAuP1UeVsqfPSxmB5s62U1islKtvXayrCzXM3f7qMxn4w4fF/cv7J
h9fexvRuGygHT3QFl0zlBUHcvNdzuJwj1Idl3ffOjfvUhjU5R5gV6Jd0vjGTYBl2
heh3Gp0rE92HAMqfkfWzBDEdz0vTLkPKsnn8x1INof4Wy/lkhtPQj9ah4yYscKQ5
PKlVaPNzMJD0kzbm26WUzZCcr0dE5e8YR1oAn8Fq9Rz/iV1E66tPW7exVqcFpWQk
rurH3bi/ob5ARtit15JQyt2QMwKEexcMaenV00jn9hs+WUJQt9Cv5tXj6JYRHltM
9fVgZIxtcO3vi6DoT/N1YPciTE/F1jAuogiE2iQRZWwqc0UkGBYZDeU5MFS9i8WX
cht6jKJqUbGn0PcIiwfj+3UZ2RylyVMHfLZoU8lB6CQXru0uBeoUZF8EtLxvOr01
cUZRWBuFhpk96CvQjA7j
=0dt+
-----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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Emanuel Falkenauer
Hi Keith,

On 19-Jan-17 01:36, Keith Marshall wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 18/01/17 23:34, Emanuel Falkenauer wrote:
>> Trouble is, it's NOT trivial to stop before that limit with printf.
>> Sure, I could print %.2f when the two digits are the only valid ones,
>>   but that would prevent me from correctly printing e.g. 0.00001234 so
>>   that it would show differently from 0.00001236 (even though both
>> only have four significant digits). I simply didn't find a reliable
>> way of printing those floats when they vary by orders of magnitude.
> "%.2f" doesn't specify significant digits -- it specifies digits
> after the radix point.  If you want to see, and compare, just so
> many significant digits, you would surely be better off using
> "%.2e", (so you don't get the leading insignificant zeros).

I got that, don't worry.  ;-)

> One other potential issue, which I neglected to mention: when you
> perform floating point calculations you may suffer rounding, or
> even cancellation effects, all of which conspire to make even less
> than the absolute maximum representable precision available.  This
> may be further compounded by differing FPU configuration between
> implementations -- e.g. it is my understanding that Microsoft
> configure the FPU to operate in 8-byte register mode, whereas
> GCC uses full 10-byte capability.  Such configuration differences
> could lead to rounding differences, even within the available
> 53-binary/15.955-decimal digit precision limit.

I agree with all you said there (and am well aware of it), but it does
turn out that I DO get identical results (thanks to the IEEE standard, I
would guess - and the fact we're running both builds on the same machines).

Now just to explain the extent of it, so you know what I'm talking
about: we're in the business of assembly optimization in large
aeronautic companies. The algorithm in question is a genetic algorithm
(i.e. an iterative and evolutive process) and depending on the size of
the data (which are usually pretty fat), it often runs for dozens of
hours in 16 threads at full throttle - that's literally TRILLIONS of
floating point calculations (including some divisions that we can't
eliminate) in a single run, and any drift due to different rounding etc.
would accumulate over the time.

Yet STILL, the Borland build ends up with exactly the same results as
the MinGW build, even after hours of running. It's pretty remarkable
indeed... and makes our debugging so much easier. But rest assured that
that consistency is also the result of an enormous effort (including
fiddling with the FPU flags) on our part to ensure portability.

>
>> I would LOVE to use _your_ printf... but remember: the whole story is
>> about comparing with Borland builds, where it's not available.
> Well, you are always likely to be on a hiding to nothing, when
> you compare apples with oranges, and expect identity -- in this
> case, how can you possibly expect consistency between Borland's
> proprietary (likely undisclosed) algorithm and A. N. Other's?

Well, given the above, I would rather say that they are just oranges of
different varieties.  ;-)

> If you want guaranteed consistency, you'd better use identically
> the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
> alternative?

Honestly, I expect the sources (if I can have them) to be littered with
external references that do not exist in Borland, making the port really
painful. I have once debugged Thunderbird (because it ceased to function
and I needed it sorely - I actually found the bug! :-)  ) and that was a
dreadful experience... so I would expect something similar in porting
MinGW's (s)printf to Borland.
But, well, maybe I'm wrong - can you instruct me how to get hold of your
(s)printf sources? Many thanks!

Best,

Emanuel

> - --
> Regards,
> Keith.
>
>


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

KHMan
In reply to this post by Keith Marshall-3
On 1/19/2017 8:36 AM, Keith Marshall wrote:

> On 18/01/17 23:34, Emanuel Falkenauer wrote:
> [snip snip]
>> I would LOVE to use _your_ printf... but remember: the whole story is
>> about comparing with Borland builds, where it's not available.
>
> Well, you are always likely to be on a hiding to nothing, when
> you compare apples with oranges, and expect identity -- in this
> case, how can you possibly expect consistency between Borland's
> proprietary (likely undisclosed) algorithm and A. N. Other's?
>
> If you want guaranteed consistency, you'd better use identically
> the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
> alternative?

Heh, I'm enjoying this thread, just kicking back now. :-) Once
Bruce's blog post was disclosed it became obvious what Tei locked
onto. Before that we were just guessing.

Totally worries me that some embedded and aerospace folks have
this kind of viewpoint. Often engineering folks are left to take
up programming on their own devices and sometimes they end up
grasping stuff in idiosyncratic ways. They can be very stubbornly
sure of their views...

I think Emanuel should seriously bite the bullet and use David
Gay's code. It's the de facto standard among Open Source projects
and probably many, many closed source projects or commercial apps
all over the planet. It's probably much faster than an
implementation of a basic conversion algorithm. Versions of it has
accumulated over 25 years of usage in countless machines. All that
is needed is just a one-time porting effort to your company's
standards. After all, in the end it's just an ASCII representation
ULP issue, CPU calcs were just fine. Just as nobody got fired for
using IBM, it is hard to say that using well-used code from Bell
Labs is bad decision-making. Looks like a no-brainer to me.

--
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Emanuel Falkenauer
Hi KHMan,

On 19-Jan-17 05:01, KHMan wrote:

> On 1/19/2017 8:36 AM, Keith Marshall wrote:
>> On 18/01/17 23:34, Emanuel Falkenauer wrote:
>> [snip snip]
>>> I would LOVE to use _your_ printf... but remember: the whole story is
>>> about comparing with Borland builds, where it's not available.
>> Well, you are always likely to be on a hiding to nothing, when
>> you compare apples with oranges, and expect identity -- in this
>> case, how can you possibly expect consistency between Borland's
>> proprietary (likely undisclosed) algorithm and A. N. Other's?
>>
>> If you want guaranteed consistency, you'd better use identically
>> the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
>> alternative?
> Heh, I'm enjoying this thread, just kicking back now. :-) Once
> Bruce's blog post was disclosed it became obvious what Tei locked
> onto. Before that we were just guessing.
>
> Totally worries me that some embedded and aerospace folks have
> this kind of viewpoint. Often engineering folks are left to take
> up programming on their own devices and sometimes they end up
> grasping stuff in idiosyncratic ways. They can be very stubbornly
> sure of their views...

Well, that's a very "interesting" viewpoint... can you explain in what
way "embedded and aerospace folks" would make worse programmers than
yourself? What kind of "folks" are YOU?!

I HATE bragging, I really do (I think others should evaluate your
worth), but you forced me to it: I actually happen to have a PhD in
computer science, besides also having an engineering degree - do you? If
you need, google me (there is definitely just one Emanuel Falkenauer on
the whole web) - and don't skip Google Scholar.
Phew... you're frankly tiring with your supposed "grandiosity".

> I think Emanuel should seriously bite the bullet and use David
> Gay's code. It's the de facto standard among Open Source projects
> and probably many, many closed source projects or commercial apps
> all over the planet. It's probably much faster than an
> implementation of a basic conversion algorithm. Versions of it has
> accumulated over 25 years of usage in countless machines. All that
> is needed is just a one-time porting effort to your company's
> standards. After all, in the end it's just an ASCII representation
> ULP issue, CPU calcs were just fine. Just as nobody got fired for
> using IBM, it is hard to say that using well-used code from Bell
> Labs is bad decision-making. Looks like a no-brainer to me.

Don't worry: just waiting for Keith to get hold of their (s)printf
sources to have a look at them.

Best,

Emanuel


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

KHMan
On 1/19/2017 2:06 PM, Emanuel Falkenauer wrote:

> Hi KHMan,
>
> On 19-Jan-17 05:01, KHMan wrote:
>> On 1/19/2017 8:36 AM, Keith Marshall wrote:
>>> On 18/01/17 23:34, Emanuel Falkenauer wrote:
>>> [snip snip]
>>>> I would LOVE to use _your_ printf... but remember: the whole story is
>>>> about comparing with Borland builds, where it's not available.
>>> Well, you are always likely to be on a hiding to nothing, when
>>> you compare apples with oranges, and expect identity -- in this
>>> case, how can you possibly expect consistency between Borland's
>>> proprietary (likely undisclosed) algorithm and A. N. Other's?
>>>
>>> If you want guaranteed consistency, you'd better use identically
>>> the same algorithm; what's to stop you compiling, and using, our printf() in your Borland builds, in place of their proprietary
>>> alternative?
>> Heh, I'm enjoying this thread, just kicking back now. :-) Once
>> Bruce's blog post was disclosed it became obvious what Tei locked
>> onto. Before that we were just guessing.
>>
>> Totally worries me that some embedded and aerospace folks have
>> this kind of viewpoint. Often engineering folks are left to take
>> up programming on their own devices and sometimes they end up
>> grasping stuff in idiosyncratic ways. They can be very stubbornly
>> sure of their views...
>
> Well, that's a very "interesting" viewpoint... can you explain in what
> way "embedded and aerospace folks" would make worse programmers than
> yourself? What kind of "folks" are YOU?!

Terribly sorry that you perceived it that way. It was not meant as
a bad thing, it's just the way things are. "Idiosyncratic" does
not imply "worse", just "different".

> I HATE bragging, I really do (I think others should evaluate your
> worth), but you forced me to it: I actually happen to have a PhD in
> computer science, besides also having an engineering degree - do you? If
> you need, google me (there is definitely just one Emanuel Falkenauer on
> the whole web) - and don't skip Google Scholar.
> Phew... you're frankly tiring with your supposed "grandiosity".

I made an observation based on this thread only, I have no
interest in checking out folks before talking to them on public
mailing lists and adjusting myself based on their qualifications.
Well, it would appear that being frank is an unloved habit on the
Internet. You grabbed Alexandru's code very quickly, praised it,
plugged it into I guess company code, then he reported a bug in
it, now would you trust that code as high-quality mature code? ...
this, over a number of far better choices.

--
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

tei.andu
In reply to this post by tei.andu
Keith, have a look here please:
http://www.exploringbinary.com/quick-and-dirty-floating-point-to-decimal-conversion
Quote from the article:
>>>Every binary floating-point number has an exact decimal equivalent, which can be expressed as a >>>decimal string of finite length.

When I started this, I didn't know about this article. Also another in-depth look at float to decimal conversion from the same author:
http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers
Anyway, your solution to define _XOPEN_SOURCE does exactly what I initially needed, so thank you again.


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

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


Message: 2
Date: Wed, 18 Jan 2017 21:39:22 +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

Guys,

This thread now seems to have run its course; sadly, the level of
pervasive wide-spread ignorance it has demonstrated is depressing.
[...]
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.


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

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

[...]

>>> Totally worries me that some embedded and aerospace folks have
>>> this kind of viewpoint. Often engineering folks are left to take
>>> up programming on their own devices and sometimes they end up
>>> grasping stuff in idiosyncratic ways. They can be very stubbornly
>>> sure of their views...
>> Well, that's a very "interesting" viewpoint... can you explain in what
>> way "embedded and aerospace folks" would make worse programmers than
>> yourself? What kind of "folks" are YOU?!
> Terribly sorry that you perceived it that way. It was not meant as
> a bad thing, it's just the way things are. "Idiosyncratic" does
> not imply "worse", just "different".

Nice try... but I will accept it, for the sake of the argument - just
please, try to be HUMBLE in what you write: not all people are
necessarily idiots (even though many actually are, indeed).

>
>> I HATE bragging, I really do (I think others should evaluate your
>> worth), but you forced me to it: I actually happen to have a PhD in
>> computer science, besides also having an engineering degree - do you? If
>> you need, google me (there is definitely just one Emanuel Falkenauer on
>> the whole web) - and don't skip Google Scholar.
>> Phew... you're frankly tiring with your supposed "grandiosity".
> I made an observation based on this thread only, I have no
> interest in checking out folks before talking to them on public
> mailing lists and adjusting myself based on their qualifications.
> Well, it would appear that being frank is an unloved habit on the
> Internet.

No, it certainly is NOT - but taking anybody else for fools just because
they disagree with you IS. I have been totally frank in my posts as well
- but I didn't consider you or anybody else automatically as being poor
idiots just because they disagreed with me - all of them could have a
valid point.

> You grabbed Alexandru's code very quickly, praised it,
> plugged it into I guess company code, then he reported a bug in
> it, now would you trust that code as high-quality mature code? ...
> this, over a number of far better choices.

Granted: there could indeed be better choices -  but with none of them
readily available at this very moment (remember: I'm keen to have a look
at Keith's (s)printf, to see how easy it would be to compile in
Borland), Alexandru's code solved a BIG part of our troubles. Sure, it
may not be perfect... but what is, really (the current printfs certainly
aren't!)? Alexandru's procedure made me go from a million clicks of
"Yeah, I know: that's a BOGUS discrepancy!" to NONE so far - that's a
big progress IMHO!
Remember: I may have a PhD, but I'm still an engineer in my soul - which
loosely means that I'm quite ready to adopt a solution that may sure be
imperfect in some "esoteric" way but that DELIVERS ENOUGH for what I
need to accomplish. And Alexandru's code did just that.

Best,

Emanuel


------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Peter Rockett
In reply to this post by tei.andu
On 19/01/17 08:21, [hidden email] wrote:
Keith, have a look here please:
http://www.exploringbinary.com/quick-and-dirty-floating-point-to-decimal-conversion
Quote from the article:
>>>Every binary floating-point number has an exact decimal equivalent, which can be expressed as a >>>decimal string of finite length.

When I started this, I didn't know about this article. Also another in-depth look at float to decimal conversion from the same author:
http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers

I think the above is exactly the sort of misleading website Keith was complaining about.

To take the calculation of the decimal equivalent of DBL_MAX example on this website, the calculation does indeed yield a 309 digit decimal number although the use of the word "significant" here is very misleading. But the question you should be asking is: what is the _precision_ of the binary floating point number. If you take the binary representation of DBL_MAX, replace the least significant digit in the mantissa with a zero and calculate the decimal equivalent, you will get another 309 digit number. But compared to the decimal equivalent of DBL_MAX, I think you will find that the bottom ~294 digits will have changed. If you got this number from a calculation, what does it tell you about the reliability of the bottom 294 digits if the smallest possible change to the binary number produces such a massive shift? Put another way, if you do arithmetic at this end of the floating point scale, the smallest change you can make is ~10^{294}. Thus only ~15 of the decimal digits are significant - the rest are completely uncertain. Passing to the decimal equivalents ultimately  clouds the issue. Floating point arithmetic is done in binary, not using decimal equivalents.

I suspect the OP's conceptual problem lies in viewing every float in splendid isolation rather than as part of a computational system. This is why printing to false precision has not attracted much uptake here. There is a fundamental difference between digits and digits that contain any useful information!

Or another take: If you plot possible floating point representations on a real number line, you will have gaps between the points. The OP is trying print out numbers that fall in the gaps!

P.

...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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Peter Rockett
In reply to this post by Emanuel Falkenauer
Guys

At the risk of wading into a thread that has become very heated, could I
drag this back to technical matters.

I think everybody (apart maybe from the OP) agrees how floating point
numbers behave. Keith makes a good point about rounding. Can I toss in
another feature that changing the compiler optimisation level often
reorders instructions meaning that rounding errors accumulate in
different ways. So changing the optimisation level often slightly
changes the numerical answers. :-\

Emanuel - The one thing I cannot grasp is that you have built s/w with a
range of toolchains, but you are very focussed on obtaining exactly the
same numerical answers - seemingly to the level of false precision - for
each build. I am struggling to see the reason for this, especially as
you are talking about a stochastic (GA) algorithm. Why is this such a
big issue for you? You mentioned you work in aerospace. Is this some
sort of ultra safety conscious aerospace certification thing?

P.

------------------------------------------------------------------------------
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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Keith Marshall-3
In reply to this post by Emanuel Falkenauer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/01/17 01:26, Emanuel Falkenauer wrote:
> But, well, maybe I'm wrong - can you instruct me how to get hold of
> your (s)printf sources? Many thanks!

I *really* shouldn't need to point you to the obvious location:
https://sourceforge.net/p/mingw/mingw-org-wsl/

The printf() code is in mingwrt/mingwex/stdio (pformat.c providing
the heart of the implementation), with David Gay's binary to string
floating point conversion code in mingwrt/mingwex/gdtoa

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

iQIcBAEBAgAGBQJYgKukAAoJEMCtNsY0flo/gusP/2iJlKIaTTtwCg5iPEp+Yym5
5e4EZkEEbtcgvmZKaGeDUh0vYmdnYkMCy046kH/R4gZxWctV/HJ7vn3BrS8UZvMe
JxolEOPfOEuBMOKXEBN9eSdpiFf40t0m8/AHDJsJMhHKimBR0SDWC0qvfg1KhR7Z
aOPpoDpBl6P/aLnkbku4LuUKHvcrNmbsh5+hyavMGybQq0N07LShBnVxoGealca2
72MsXShQGzxtnY+9KHHZ7ERChW8vjakYWDQ+clC2kYortMd82/l6uqgnapqUx5QA
DpSW0X6a2+CDqiqrrE1B1OvSptMEJfTadBPMvJvNjFagKumU/FeVcSLB7jCgHjEy
nDmP61zbVlmd+YOhbRRyGjzKm31khfd7ALn94+pWT1brUBS4LbS/N5U4Nvd1VPaG
Xu6jK8ulqFLQJb7P0lAtNAXxAaDbFcjOxcuZDY6eszGb7Hr5mDmi2I5rjIhbTIw8
Hr/79vpoGQE07gj5aU1KXbKizggMFiXsWxalo1bSv4eoPl/xSM4LsIZOifdwIaqe
SghCSyUkAsoKQUnb9zAG/tEwFBCsnZfqHXYk20w031GqMRTCR2tAhVZktFEL9Fgy
Q9km+g5YUKk2xWbhwFw055CwdFV2/xguLlD2aPjhAR/rgLyFf/P8Pj/hlE/HhYZW
2xs1yru0WE/qzwQl0LDj
=u25I
-----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
|  
Report Content as Inappropriate

Re: msvcrt printf bug

Keith Marshall-3
In reply to this post by Peter Rockett
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/01/17 11:19, Peter Rockett wrote:

> On 19/01/17 08:21, [hidden email] wrote:
>> Keith, have a look here please:
>> http://www.exploringbinary.com/quick-and-dirty-floating-point-to-decimal-conversion
>> Quote from the article:
>>>>> Every binary floating-point number has an exact decimal equivalent
>> <http://www.exploringbinary.com/number-of-decimal-digits-in-a-binary-fraction/>,
>> which can be expressed as a decimal string of finite length.
>>
>> When I started this, I didn't know about this article. Also another
>> in-depth look at float to decimal conversion from the same author:
>> http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers 
>> <http://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers/>
>
> I think the above is exactly the sort of misleading website Keith was
> complaining about.

Indeed, yes.  I stumbled across that same website several years
ago: I immediately dismissed it as the gigantic pile of bovine
manure which it so clearly represents.  Sadly, there are far too
many mathematically challenged programmers who are gullible enough
to accept such crap at face value; (and far too much similarly
ill-informed nonsense pervading the internet).

> If you take the binary representation of DBL_MAX, replace the least
> significant digit in the mantissa with a zero and calculate the
> decimal equivalent, you will get another 309 digit number. But
> compared to the decimal equivalent of DBL_MAX, I think you will find
> that the bottom ~294 digits will have changed. If you got this number
> from a calculation, what does it tell you about the reliability of
> the bottom 294 digits if the smallest possible change to the binary
> number produces such a massive shift?

It tells us, as I've said before, that those excess ~294 digits are
meaningless garbage, having no mathematical significance whatsoever.

> Put another way, if you do arithmetic at this end of the floating
> point scale, the smallest change you can make is ~10^{294}. Thus only
> ~15 of the decimal digits are significant - the rest are completely
> uncertain. Passing to the decimal equivalents ultimately clouds the
> issue. Floating point arithmetic is done in binary, not using decimal
> equivalents.
>
> I suspect the OP's conceptual problem lies in viewing every float in
> splendid isolation rather than as part of a computational system.
> This is why printing to false precision has not attracted much uptake
> here. There is a fundamental difference between digits and digits
> that contain any useful information!

Exactly so.  Nicely elucidated, Peter.  Thank you.

> Or another take: If you plot possible floating point representations
> on a real number line, you will have gaps between the points. The OP
> is trying print out numbers that fall in the gaps!

And, taken to its ultimate, there are an infinite number of possible
numbers falling in each gap: each of these is an equally speculative
possible misrepresentation of the reality conveyed by the actual bits encoding the number at one or other end of the gap.

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

iQIcBAEBAgAGBQJYgMiMAAoJEMCtNsY0flo/GVkQAI8kkW2uI45R2Qeb+bw0UFB9
7j7GhzzYGRv5Xoo4NA4aDb1D9fVUWhnncIcfsdCuYriYdGRjaqJsrFEUvL5gBIpi
61QfgdD4dJvi1mRDc5i3zrV2YErjAqYUgb2HcxZkuWon3G6C5GgppFV9JoDVinNn
Zr0w9B8vvIDiKxrbuLQL9cZ6xRJDvwPlf7KwqAt/uABqiBrHM7uBE/Jw1rlF2arj
om7MBp1rQ35jZSrTGLEOXtBWSXQ7r320iJoijqZSR1nC6nYwrUqnKNyoChAt51Jp
0M/ODWj8yJf5+6c/kMpy5p8hW5Wg5z4osOl6ka4EvHfx3IfJLSKoP5PS4siTWOWM
oGq0wDqO3lDiGkTG9qU2JVQp/LOwDvU1H7DBTB0xoe3/TGg8ef5lSSVqicj8dSid
lzXXsuxvgOqEgjkj02MiEW4F1DwYS5W9DI97n/Lgn/Mrw+YAlWcbuli8GpMHiXaS
oxPOpTK/78qC61mJqbsDxtBoXoqbLOacxQFWWr+Jt+iZU2/k7XcL1L2eMYWyJbfN
bFeZjNXfIVgrsJBB3aYYgixeOi46yc2ubHmZsOaTk0xUUwHyO2Ry2aknG/02LWdE
4fWyFOvPuh1o3rcyDEOr1ohMAMAm+XMS04XnvutrNQiPlESv4vTiJuGimLo9u/Gk
0ubaTsuMi5EvZYtdNseN
=LRHr
-----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
1234
Loading...