www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - typeid(double) does not respect NaNs

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7836

Upon closer inspection, however, it seems that this may have been
deliberate??? Here's the code from rt/typeinfo/ti_double.d:

    class TypeInfo_d : TypeInfo
    {
        // ...

        static bool _equals(double f1, double f2)
        {
            return f1 == f2 ||
                    (f1 !<>= f1 && f2 !<>= f2);
        }

        static int _compare(double d1, double d2)
        {
            if (d1 !<>= d2)         // if either are NaN
            {
                if (d1 !<>= d1)
                {
                    if (d2 !<>= d2)
                        return 0;
                    return -1;
                }
                return 1;
            }
            return (d1 == d2) ? 0 : ((d1 < d2) ? -1 : 1);
        }

        // ...
    }

It seems as though NaNs are explicitly being checked for, and _equals is
made to return true when comparing two NaNs, and some black magic is
being used to determine the sign of the comparison in _compare.

Why is this? Isn't this a violation of the IEEE floating-point spec??

More to the point, *if* typeinfo isn't meant to match == for whatever
reason, then why is it being used as the standard of comparison for AA
keys?


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
Jul 08 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:

 More to the point, *if* typeinfo isn't meant to match == for 
 whatever
 reason, then why is it being used as the standard of comparison 
 for AA
 keys?


I guess we need NaN == NaN to be true for AA keys, no ?
Jul 08 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:

 On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:

More to the point, *if* typeinfo isn't meant to match == for whatever
reason, then why is it being used as the standard of comparison for
AA keys?


 
 I guess we need NaN == NaN to be true for AA keys, no ?


Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836

So, should NaN == NaN for AA keys, or not?


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
Jul 09 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:

 On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:

 On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:

More to the point, *if* typeinfo isn't meant to match == for 
whatever
reason, then why is it being used as the standard of 
comparison for
AA keys?


 
 I guess we need NaN == NaN to be true for AA keys, no ?


 Not according to: 
 http://d.puremagic.com/issues/show_bug.cgi?id=7836

 So, should NaN == NaN for AA keys, or not?


 T


I think it was not decided yet. From language coherency point of 
view NaN != NaN like in general case, from usefulness perspective 
you don't need several nans in AA array.
Jul 09 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote:

 On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:

 On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:

 On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:

More to the point, *if* typeinfo isn't meant to match == for
whatever
reason, then why is it being used as the standard of
comparison for
AA keys?


 
 I guess we need NaN == NaN to be true for AA keys, no ?


 
 Not according to:
 http://d.puremagic.com/issues/show_bug.cgi?id=7836
 
 So, should NaN == NaN for AA keys, or not?
 
 
 T


 
 I think it was not decided yet. From language coherency point of
 view NaN != NaN like in general case, from usefulness perspective
 you don't need several nans in AA array.


I'd think that having NaN != NaN would cause serious problems with retrieving 
any elements inserted with NaN as a key, but given how floating point values 
work, using them as the key for an AA is arguably completely broken to begin 
with as comparing floating point values for equality is generally just plain 
wrong. That being the case, I'd argue in favor of language consistency and 
just point out to anyone that runs into problems that using a floating point 
type as the key type of an AA is a stupid thing to do to begin with.

- Jonathan M Davis
Jul 09 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 That being the case, I'd argue in favor of language consistency


Here I'd like D AAs act as Python dicts. This means breaking 
"consistency".

Bye,
bearophile
Jul 09 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 09, 2013 19:19:18 bearophile wrote:

 Jonathan M Davis:

 That being the case, I'd argue in favor of language consistency


 
 Here I'd like D AAs act as Python dicts. This means breaking
 "consistency".


I'm afraid that you'll have to be more specific in terms of what you mean.

But as far as I can tell, using floating point values as keys in an AA is 
fundamentally broken, because using == with floating point values is 
fundamentally broken. As such, I see no reason why it should matter that NaN 
is effectively unusable as an AA key.

- Jonathan M Davis
Jul 09 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I'm afraid that you'll have to be more specific in terms of 
 what you mean.


Please ignore what I have said...



 As such, I see no reason why it should matter that NaN
 is effectively unusable as an AA key.


OK.

Bye,
bearophile
Jul 09 2013
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 9 July 2013 at 21:12:15 UTC, Jonathan M Davis wrote:

 On Tuesday, July 09, 2013 19:19:18 bearophile wrote:

 Jonathan M Davis:

 That being the case, I'd argue in favor of language 
 consistency


 
 Here I'd like D AAs act as Python dicts. This means breaking
 "consistency".


 I'm afraid that you'll have to be more specific in terms of 
 what you mean.

 But as far as I can tell, using floating point values as keys 
 in an AA is
 fundamentally broken, because using == with floating point 
 values is
 fundamentally broken. As such, I see no reason why it should 
 matter that NaN
 is effectively unusable as an AA key.

 - Jonathan M Davis


Using floating point as keys can make sense in an ordered 
container actually. Just thought I'd point it out.

Basically, instead of looking for specific keys, you try to 
position yourself between two entries.

But since our AA's are hashed sets, then no, it doesn't make 
sense for us."
Jul 09 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 9 July 2013 at 17:04:47 UTC, Jonathan M Davis wrote:

 On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote:

 On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:

 On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:

 On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:

More to the point, *if* typeinfo isn't meant to match == 
for
whatever
reason, then why is it being used as the standard of
comparison for
AA keys?


 
 I guess we need NaN == NaN to be true for AA keys, no ?


 
 Not according to:
 http://d.puremagic.com/issues/show_bug.cgi?id=7836
 
 So, should NaN == NaN for AA keys, or not?
 
 
 T


 
 I think it was not decided yet. From language coherency point 
 of
 view NaN != NaN like in general case, from usefulness 
 perspective
 you don't need several nans in AA array.


 I'd think that having NaN != NaN would cause serious problems 
 with retrieving
 any elements inserted with NaN as a key, but given how floating 
 point values
 work, using them as the key for an AA is arguably completely 
 broken to begin
 with as comparing floating point values for equality is 
 generally just plain
 wrong. That being the case, I'd argue in favor of language 
 consistency and
 just point out to anyone that runs into problems that using a 
 floating point
 type as the key type of an AA is a stupid thing to do to begin 
 with.

 - Jonathan M Davis


That what I meant, and you explained it much better.
Jul 09 2013