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 lemburg
Recipients Arfrever, Giovanni.Bajo, PaulMcMillan, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, dmalcolm, koniiiik, lemburg, serhiy.storchaka, vstinner
Date 2012-11-07.11:19:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <509A43AF.5090906@egenix.com>
In-reply-to <1352286360.06.0.465737958377.issue14621@psf.upfronthosting.co.za>
Content
On 07.11.2012 12:06, Armin Rigo wrote:
> 
> Armin Rigo added the comment:
> 
> Marc-André: estimating the risks of giving up on a valid query for a truly random hash, at an overestimated one billion queries per second, in a 2/3 full dictionary:
> 
> * for 1000: 4E159 years between mistakes
> 
> * for 100: 12.9 years between mistakes
> 
> * for 150: 8E9 years between mistakes
> 
> * for 200: 5E18 years between mistakes
> 
> So while it seems that 100 might be a bit too small, using 150 to 200 is perfectly safe (and that's "perfect" in the sense that a computer will encounter random hardware errors at a higher rate than that).

I used the 1000 limit only as example. In tests Victor and I ran (see the
original ticket from a few months ago), 200 turned out to be a reasonable
number for the default maximum hash collision value.

I'm not sure about the slot collision limit. We'd have to run more tests
on those.
History
Date User Action Args
2012-11-07 11:19:16lemburgsetrecipients: + lemburg, arigo, vstinner, christian.heimes, benjamin.peterson, Arfrever, alex, dmalcolm, Giovanni.Bajo, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara
2012-11-07 11:19:16lemburglinkissue14621 messages
2012-11-07 11:19:16lemburgcreate