A case for valueless AA's?
Steven Schveighoffer
schveiguy at yahoo.com
Wed Mar 30 05:56:47 PDT 2011
On Tue, 29 Mar 2011 23:02:35 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> On 3/29/2011 8:37 PM, Jonathan M Davis wrote:
>> We now have std.container.RedBlackTree, which can be used as a set, but
>> it is
>> a tree rather than a hash table.
>>
>> - Jonathan M Davis
>
> This isn't a very good set. It doesn't even support basic set
> primitives like intersection, difference, union, etc.
std.container.RedBlackTree supports the standard methods, and not much
else. I am not the architect for std.container, so I did not want to add
methods that might some day be superseded by further additions to the
std.container regime.
dcollections does support these primitives, so the code already exists, I
just am not sure of the interface Andrei wants.
> Furthermore, most programs will probably want a hash set. A tree set is
> only better when you don't have a good hash function or worst case
> performance is more important than average case.
A tree-based set's advantage over hash-based is that it's ordered. This
means things like insertions and deletions do not affect ranges, whereas
an insertion in a hash set can cause a rehash.
In addition to that, an ordered set provides excellent slicing ability
(dcollections supports this).
So it depends on your needs. Tree sets are definitely lower performing, I
think Hashes win out pretty much there.
> I'm not saying there's anything wrong with RedBlackTree. It's a
> perfectly good data structure to implement a set on top of. It's just
> that it's not a "real" set type because it's not meant to be.
I found that the primitives in RedBlackTree suffice to make a set except
for intersection, which cannot be done in a generic fashion with high
performance. This function exists in dcollections, and can easily be
added to std.container.RedBlackTree.
-Steve
More information about the Digitalmars-d
mailing list