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