>> Also, I believe that max "reasonable" integer range of no collision
>> is (-2305843009213693951, 2305843009213693951), ...
> Any range that does _not_ contain both -2 and -1 (-1 is an annoying
> special case, with hash(-1) == hash(-2) == -2), and spans no more than
> sys.hash_info.modulus
[Kyle]
> ...
> For some reason, I had assumed in the back of my head (without
> giving it much thought) that the average collision rate would be the
> same for set items and dict keys. Thanks for the useful information.
I know the theoretical number of probes for dicts, but not for sets
anymore.
Tim Peters wrote:
> Sorry! A previous attempt to reply got sent before I typed anything :-(
No worries, I only saw the link in the footer to the PSF CoC, and I was
mildly concerned for a moment. My first thought was "Oh no, what did I
do?". Thanks for clearing that up (:
> The collision
Chris Angelico wrote:
> I think this is an artifact of Python not having an empty set literal.
> [snip]
> When both use the constructor call or both use a literal, the
> difference is far smaller. I'd call this one a wash.
Ah, good catch. I hadn't considered that it would make a substantial
Sorry! A previous attempt to reply got sent before I typed anything :-(
Very briefly:
> >>> timeit.timeit("set(i for i in range(1000))", number=100_000)
[and other examples using a range of integers]
The collision resolution strategy for sets evolved to be fancier than
for dicts, to reduce
On Mon, Dec 23, 2019 at 8:56 PM Kyle Stanley wrote:
>
> > To begin with, please compare performance of dict-with-None-values to that
> > of a set, for operations that can be expressed by both (e.g. both have
> > update()).
>
> Good idea. It would be useful to have a baseline comparison. I
David Mertz writes:
> Even though I was the first person in this thread to suggest
> collections.OrderedSet, I'm "meh" about it now. As I read more and played
> with the sortedcollections package, it seemed to me that while I might want
> a set that iterated in a determinate and meaningful
On Tue, Dec 24, 2019 at 1:57 PM Kyle Stanley wrote:
> Add (much faster for dicts):
> >>> timeit.timeit("s = set(); s.add(0)", number=100_000_000)
> 13.330938750001224
> >>> timeit.timeit("d = {}; d[0] = None", number=100_000_000)
> 5.788865385999088
I think this is an artifact of Python not
> To begin with, please compare performance of dict-with-None-values to
that of a set, for operations that can be expressed by both (e.g. both have
update()).
Good idea. It would be useful to have a baseline comparison. I emboldened
the comparisons with a notable difference.
Tested on:
Version:
Even though I was the first person in this thread to suggest
collections.OrderedSet, I'm "meh" about it now. As I read more and played
with the sortedcollections package, it seemed to me that while I might want
a set that iterated in a determinate and meaningful order moderately often,
insertion
To begin with, please compare performance of dict-with-None-values to that
of a set, for operations that can be expressed by both (e.g. both have
update()).
On Mon, Dec 23, 2019 at 18:08 Kyle Stanley wrote:
> Larry Hastings wrote:
> > a hypothetical collections.OrderedSet would probably work
Larry Hastings wrote:
> a hypothetical collections.OrderedSet would probably work just fine.
I'm also in agreement with adding a collections.OrderedSet. There certainly
seems to be a practical use case for a Set that preserves insertion order,
but with significant push back to modifying the
12 matches
Mail list logo
