This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Dmitry Rubanovich, methane, rhettinger, serhiy.storchaka, tim.peters, xiang.zhang
Date 2017-06-18.19:02:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1497812524.44.0.477697496634.issue30671@psf.upfronthosting.co.za>
In-reply-to
Content
I don't see a reason to keep this open, but I haven't been able to follow the OP's line of argument.  My best _guess_ is that they're chasing illusions based on not understanding (or grossly undervaluing) that the primary point of the perturb logic is to incrementally fold in hash code bits that _didn't_ have any effect at all on the initial table index.  It's true that for a hash table with 2**p slots, the current scheme could be improved in several ways _if_ hash codes only had p bits.  To judge from the Python code they posted, they either (erroneously) assumed that was the case, or offhandedly dismissed the potential value of folding in hash code bits beyond the p'th most significant.

But, since I've been unable to follow the argument, I could be wrong about all that.  So if they don't clarify within a few days, I'll close this.
History
Date User Action Args
2017-06-18 19:02:04tim.peterssetrecipients: + tim.peters, rhettinger, methane, serhiy.storchaka, xiang.zhang, Dmitry Rubanovich
2017-06-18 19:02:04tim.peterssetmessageid: <1497812524.44.0.477697496634.issue30671@psf.upfronthosting.co.za>
2017-06-18 19:02:04tim.peterslinkissue30671 messages
2017-06-18 19:02:04tim.peterscreate