Ariel Scolnicov wrote:
>Eric Roode <[EMAIL PROTECTED]> writes:
>
>[...]
>
>> The underlying problem is that arrays don't make SENSE as an
>> implementation for sets. What is the value of:
>
>But all of the following DO make sense as implementations for sets,
>depending on your application:
>
>* Sorted lists
(1, 1, 2, 2, 3, 3, 4, 5) is as invalid a set as (1, 2, 3, 1, 2, 3, 4, 5).
>* Lists with guaranteed unique elements
Yes -- we call these "hash keys" ;-)
Anything else is reinventing the wheel.
>* Lists (as implementations for multisets, with you favourite
> definitions of the operations)
Not sure I follow you here.
>* Hashes
Yes.
>* Bit vectors
Yes, I forgot about these. Thanks for bringing this up. _Mastering
Algorithms_ goes into much detail about how to represent and
manipulate sets as bit vectors.
>* Integers
Only inasmuch as the integers are used to store bit vectors, which
see above.
>* Trees
>* Balanced trees
No built-in language support for these structures, unless you're
proposing adding such...?
[...]
>When I started reading this thread, I was *sure* it would be
>immediately clear that sets are bit vectors, drawn on some
>pre-specified world!
Bit vectors do have their problems, vis a vis mapping the set
universe onto the bit positions, adding and deleting elements from
the set universe, etc. But they can be a useful way of representing
sets, so thanks for bringing them up.
----------------------------------------------------------------------
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer 'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation '.r', 'h ', 'uj', 'p ', 'ts';
