-
Notifications
You must be signed in to change notification settings - Fork 13.4k
NaN when hashed should have a random hash value #4510
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I believe this is exactly addressing the problem that came up. Thanks for pointing it out! I'm happy to follow Russ' lead here. |
I... am not sure about this! At least let's discuss it. I am trying to remember what precisely we concluded when discussing this after a recent meeting. @pcwalton ? |
I am going to close this, since I believe the problem is adequately and better addressed by #5283. |
No float-keyed hashtables? |
@graydon: I think there are ways to work around it, like implementing |
The underlying issue isn't the equality, it's the hashing itself. It's worth reading the linked article in detail if you haven't yet -- the behavior it describes is intended to maintain the operational invariants of a map. |
@graydon: The hashing isn't the direct cause of the issue though, |
@graydon TotalOrd would have a defined ordering and equality for NaN (just as e.g. Java does; check out the rules for Double.equals(), |
Note that there is no need to fail dynamically when a NaN is encountered. The behavior of TotalOrd (or just Ord, as pcwalton suggested) is just different from the behavior of partial-comparisons (i.e., the |
(Not that the situations in Java and Racket are directly analogous either. Well, Java basically is. Racket somewhat less so, and I don't claim a deep understand of their solution, but @jbclements and I did some experimentation and found that there is some special treatment around NaN to deal with these inconsistencies.) |
Ok, so after some discussion I'm reasonably OK with closing this, but I'll make notes here:
This matches the precedent of other languages and I think the intent of the IEEE committee in adding |
Just to add something I wrote on IRC: my one concern with using conditions is that the method used to hash/compare NaN should really be associated with the data structure, but conditions are dynamically scoped, so making things customizable via conditions opens the door to data structure incoherence. |
http://research.swtch.com/randhash for more discussion.
The text was updated successfully, but these errors were encountered: