On Tue, 29 Mar 2011 23:02:35 -0400, dsimcha <dsim...@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

Reply via email to