May 07, 2012
On Sat, 05 May 2012 13:14:27 -0400, bioinfornatics <bioinfornatics@fedoraproject.org> wrote:

> Dear, i hope i will got some answer from druntime/phobos dev .
> A set is an array of unique element:
>>>> set( 1, 5, 7, 1, 7)
> give this array => [1, 5, 7]
>
> Currently in D the hack it is to use an associative array with any
> value.
> byte[size_t] a = [ 1:0, 5:0, 7:0, 1:0, 7:0 ];
>
> then it is easy to have a set in D just add a syntax or a built-in where
> use associative array without using value.
>
> I hope really this little feature and seem really easy to add
>
>
> thanks a lot for your great works

http://www.dsource.org/projects/dcollections

-Steve
May 07, 2012
On Monday, 7 May 2012 at 06:05:47 UTC, Russel Winder wrote:
> I wonder if the tradition of exposing HashMap and TreeMap was a
> disservice by C++ and Java? Map and Set are programmer level concepts.
> Where there are algorithmic issues that require knowing about trees or
> has tables then the programmer is not working at the map or set level.

Some people say that abstracting away big-O complexity should be a capital offense, and I agree (preferably in slightly less drastic words, though). Additionally, a tree-based map is naturally ordered, whereas a hash map is not – for me, that's enough to warrant exposing what seems to be a »detail«, at least in languages like C++ and D.

David
May 07, 2012
On Mon, 07 May 2012 08:52:56 -0400, David Nadlinger <see@klickverbot.at> wrote:

> On Monday, 7 May 2012 at 06:05:47 UTC, Russel Winder wrote:
>> I wonder if the tradition of exposing HashMap and TreeMap was a
>> disservice by C++ and Java? Map and Set are programmer level concepts.
>> Where there are algorithmic issues that require knowing about trees or
>> has tables then the programmer is not working at the map or set level.
>
> Some people say that abstracting away big-O complexity should be a capital offense, and I agree (preferably in slightly less drastic words, though). Additionally, a tree-based map is naturally ordered, whereas a hash map is not – for me, that's enough to warrant exposing what seems to be a »detail«, at least in languages like C++ and D.

Yes, I fully agree.

That being said, I think it's also important that some functions/structures should not have to care what algorithm is used.  That's one of the reasons I like having the interface design that dcollections uses.

-Steve
May 07, 2012
On Monday, 7 May 2012 at 05:54:04 UTC, Jonathan M Davis wrote:
> On Monday, May 07, 2012 06:49:00 Russel Winder wrote:
>> Any language with which the programmer has to develop their  own set implementation is sadly lacking.
>> 
>> It is true that set can be implemented using a map, but this  should be seen as implementation detail, not as programmer level tool. It indicates that set should exist where set does. So for C++ it  is in the standard library, for Python it is a built-in (*).
>> 
>> The conclusion for D is straightforward. Which issue to I go  to to vote?
>
> We have RedBlackTree, so we have a set already. What we don't  have is a HashSet. However, once the custom allocator stuff has been  sorted out, I'd fully expect to have one in std.container along with a variety  of other container types which we really should have but don't.

 Been thinking about this a little. With arrays, fixed arrays and associative arrays being built in, you don't need set to be built in. First it's already hash-map like so it's going to be O(1), and the data being kinda useless can either be a byte, and int (offset to an array perhaps), or to itself.

 It has the added benefit of being a sparse array when asked of it. So aside from a slight loss in memory space which is only going to be critical in embedded systems. The only thing the builtins don't offer is a way to automatically sort the data, which the libraries and RedBlackTree's do quite well so far as I can see.
1 2
Next ›   Last »