May 07, 2012 Re: [Feature Request] Adding to D lang "set" built-in | ||||
---|---|---|---|---|
| ||||
Posted in reply to bioinfornatics | 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 Re: [Feature Request] Adding to D lang "set" built-in | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 Re: [Feature Request] Adding to D lang "set" built-in | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: [Feature Request] Adding to D lang "set" built-in | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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.
|
Copyright © 1999-2021 by the D Language Foundation