Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix terminology in comment and add more design rationale. #3335

Merged
merged 2 commits into from
Sep 5, 2017
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions Objects/setobject.c
Original file line number Diff line number Diff line change
Expand Up @@ -12,16 +12,23 @@

To improve cache locality, each probe inspects a series of consecutive
nearby entries before moving on to probes elsewhere in memory. This leaves
us with a hybrid of linear probing and open addressing. The linear probing
us with a hybrid of linear probing and randomized probing. The linear probing
reduces the cost of hash collisions because consecutive memory accesses
tend to be much cheaper than scattered probes. After LINEAR_PROBES steps,
we then use open addressing with the upper bits from the hash value. This
helps break-up long chains of collisions.
we then use more of the upper bits from the hash value and apply a simple
linear congruential random number genearator. This helps break-up long
Copy link
Contributor

@MSeifert04 MSeifert04 Sep 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two whitespace after "linear".

Also shouldn't it be "This helps to break-up long..."? or "This helps break-up of long...." I'm not a native speaker so ignore that if it's incorrect.

chains of collisions.

All arithmetic on hash should ignore overflow.

Unlike the dictionary implementation, the lookkey function can return
NULL if the rich comparison returns an error.

Use cases for sets differ considerably from dictionaries where looked-up
keys are more likely to be present. In contrast, sets are primarily
about membership testing where the presence of an element is not known in
advance. Accordingly, the set implementation needs to optimize for both
the found and not-found case.
*/

#include "Python.h"
Expand Down