Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug




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
> MinGW-users@xxxxxxxxxxxxxxxxxxxxx
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe