D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 7836 - NaNs inside associative array don't use normal FP equality
Summary: NaNs inside associative array don't use normal FP equality
Status: RESOLVED DUPLICATE of issue 5999
Alias: None
Product: D
Classification: Unclassified
Component: druntime (show other issues)
Version: D2
Hardware: x86 All
: P2 normal
Assignee: No Owner
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2012-04-05 17:45 UTC by bearophile_hugs
Modified: 2013-11-07 08:47 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description bearophile_hugs 2012-04-05 17:45:03 UTC 
I don't know if this is a bug, or if here D/DMD is working as designed. I am not sure.

This code shows that floating point NaNs are not tested with == inside associative arrays (because NaNs != NaNs):

import std.stdio: writeln;
void main() {
    int[double] aa;
    aa[double.nan] = 1;
    writeln(aa);
    aa[double.nan] = 2;
    writeln(aa);
}


Output DMD 2.059beta:

[nan:1]
[nan:2]



Python uses == to compare dict (associative array) keys, so NaNs can't overwrite each other:

>>> a = {}
>>> a[float("nan")] = 1
>>> a
{nan: 1}
>>> a[float("nan")] = 2
>>> a
{nan: 1, nan: 2}


So maybe DMD has to act as Python in this case.
Comment 1 hsteoh 2012-04-14 07:28:41 UTC 
This is an AA implementation bug. Internally, AA's use bitwise comparison, which is wrong in many cases.
Comment 2 hsteoh 2013-07-08 19:57:27 UTC 
Actually, this bug has nothing to do with AA's. The problem is that double's typeinfo.equals and typeinfo.compare does not respect NaNs:

import std.stdio: writeln;
void main() {
    double x = double.nan, y = double.nan;
    writeln(x == y); // prints false (OK)
    writeln(typeid(double).equals(&x, &y)); // prints true (WRONG)
    writeln(typeid(double).compare(&x, &y)); // prints 0 (WRONG)
}
Comment 3 Denis Shelomovskii 2013-11-07 08:47:27 UTC 

*** This issue has been marked as a duplicate of issue 5999 ***