“ISet”的界面是什么？ [英] What interface for "ISet"

问题描述

我有一些具有Set结构的数据，即成员资格，插入

并且删除速度很快（O（1），哈希）。我找不到一个System.Collections

界面，它与套装自然提供的操作相匹配。


- ICollection无法决定收容

- IList承诺自然数的可索引性，这不是可实现的（因为我哈希元素，而不是排序它们）。

- IDictionary绝对不是类似的。


当然，我可以定义自己的ISet。真的没有

" .NET"与Set数据结构匹配的接口？


接口ISet：ICollection {

void Add（Object）;

void Remove（Object ）;

bool包含（对象）;

}


如果我定义自己的ISet，我将介绍所有问题

与其他图书馆的合作，这些图书馆将使用Set

界面的其他名称。


任何想法的好方案这个问题？


-

Helge

I''ve got some data that has Set structure, that is membership, insert
and delete is fast (O(1), hashing). I can''t find a System.Collections
interface that matches the operations naturally offered by Sets.

- ICollection cannot decide containment
- IList promises indexability by the natural numbers, which is not
achievable (since i hash elements, not sort them).
- IDictionary is definatly not setlike.

Although I can, of course, define my own "ISet" is there really no
".NET" interface that matches the Set datastructure?

interface ISet: ICollection {
void Add(Object);
void Remove(Object);
bool Contains(Object);
}

If i define my own ISet, I will introduce all the problems of
cooperation with other libraries, which will use other names for the Set
interface.

Any ideas for nice solutions to this problem?

--
Helge

推荐答案

我想我我没有看到从IList派生出来的问题，或者至少在
中创建一个只包含IList对象的Set对象，并且没有
暴露其接口。

I guess I''m not seeing the problem with deriving from IList or, at least,
creating a Set object that simply contains an IList object and doesn''t
expose its interfaces.

如果我定义自己的ISet，我将介绍与其他库合作的所有问题，其他库将使用Set
接口的其他名称。


您是否有任何理由认为您的名称空间不会照顾任何问题的
与其他图书馆合作？

-

--- Nick Malik [微软]

MCSD，CFPS，认证Scrummaster
http://blogs.msdn.com/nickmalik

免责声明：本论坛中发表的意见是我自己的意见，而不是我雇主的b $ b代表。

我不代表我的雇主回答问题。我只是一个帮助程序员的
程序员。

-

" Helge Jensen" <他********** @ slog.dk>在消息中写道

新闻：％2 **************** @ TK2MSFTNGP12.phx.gbl ...我有一些数据已经设置结构，即成员资格，插入
和删除很快（O（1），哈希）。我找不到一个System.Collections
接口，它与Sets自然提供的操作相匹配。

- ICollection无法决定遏制
- IList承诺自然数的可索引性，这是不可实现的（因为我哈希元素，而不是它们排序）。
- IDictionary绝对不是类似的。

虽然我可以，当然，定义我自己的的ISet"真的没有
.NET吗？接口匹配Set数据结构？

接口ISet：ICollection {
void Add（Object）;
void Remove（Object）;
bool Contains（Object）;
}

如果我定义自己的ISet，我将介绍与其他库合作的所有问题，其他库将使用Set
接口的其他名称。

对这个问题有好的解决方案吗？

-
Helge

If i define my own ISet, I will introduce all the problems of
cooperation with other libraries, which will use other names for the Set
interface.
Is there any reason that you believe that your namespace wouldn''t take care
of any "problems" with cooperation with other libraries?
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I''m just a
programmer helping programmers.
--
"Helge Jensen" <he**********@slog.dk> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... I''ve got some data that has Set structure, that is membership, insert
and delete is fast (O(1), hashing). I can''t find a System.Collections
interface that matches the operations naturally offered by Sets.

- ICollection cannot decide containment
- IList promises indexability by the natural numbers, which is not
achievable (since i hash elements, not sort them).
- IDictionary is definatly not setlike.

Although I can, of course, define my own "ISet" is there really no
".NET" interface that matches the Set datastructure?

interface ISet: ICollection {
void Add(Object);
void Remove(Object);
bool Contains(Object);
}

If i define my own ISet, I will introduce all the problems of
cooperation with other libraries, which will use other names for the Set
interface.

Any ideas for nice solutions to this problem?

--
Helge

Nick Malik [微软]写道：

Nick Malik [Microsoft] wrote:

我想我没有看到从IList派生的问题，或者至少，创建一个只包含IList对象的Set对象没有公开它的接口。


IList的基本属性是自然数的可索引性，

0，...，list.Count。


我正在高效地表示网络，插入，删除

，会员资格必须非常高效。对于节点来说，平等可能相当昂贵，但是存在良好的哈希函数。


最好的方法（基于网络中的实际数据） ）是使用

哈希，这给我（摊销最坏情况）O（1）操作所有

这些操作，其中最多1-2等于操作完成。


使用排序列表会产生（最坏情况）O（logN） - 操作

成员资格和（最坏情况）O（ n）插入和删除操作（移动

所有其他元素）。


虽然排序列表解决方案将为我提供数据结构

适合存在的System.Collections界面，这将是一个相当糟糕的

移动性能...特别是因为我没有任何实际用途

索引，仅用于收容，插入和删除。


因此，底层数据结构只能实现索引

操作（这[int i] {get;通过迭代所有元素，计算为

它继续。对我来说，给我的数据结构应该用作IList的印象非常糟糕。

I guess I''m not seeing the problem with deriving from IList or, at least,
creating a Set object that simply contains an IList object and doesn''t
expose its interfaces.
The basic property of IList is indexability by the natural numbers,
0,...,list.Count.

I am doing an efficient representation of networks, insertion, deletion
and membership must be decidable very efficiently. Equality can be
rather expensive to decide for the nodes, but a good hasing function exists.

The best approach (based on the actual data in the network) is to use
hashing, which gives me (amortized worst-case) O(1) operation on all
these operations, where at most 1-2 equals operations would get done.

Using a sorted list would yield (worst-case) O(logN)-operation for
membership and (worst-case) O(n) insert and delete operations (moving
all the other elements).

While the sorted-list solution would provide me with a data-structure to
fit an existsing System.Collections interface, it would be a rather bad
move for performance... especially since I don''t have any real use for
the indexing, only for containment, insert and delete.

So, the underlying data-structure can only implement the indexing
operation (this[int i] { get; }) by iterating all elements, counting as
it goes along. It would be a very bad idea for me to give users the
impression that my data-structure should be used as a IList.

如果我定义自己的ISet，我将介绍与其他库合作的所有问题，其他库将使用Set
接口的其他名称。

If i define my own ISet, I will introduce all the problems of
cooperation with other libraries, which will use other names for the Set
interface.

你有没有理由相信你的命名空间不会照顾任何问题。与其他图书馆合作？

Is there any reason that you believe that your namespace wouldn''t take care
of any "problems" with cooperation with other libraries?

合作问题不会源于名字的冲突。


在C＃（和JAVA， python，C ++，...）

的接口定义是最常见的数据结构。


这为不同的库建立了一致的接口：I

可以将IDictionary从一个独立的库传递给另一个独立的库。所以具有相同属性的
数据结构可用于各个库。


库自然选择语言提供

用于传递与这些接口匹配的数据结构的接口

（IDictionary，IList，C＃中的枚举器 - Set，Map，Iterator ......在JAVA中

- std :: set< T>，std :: map< T，R>，std :: iterator_traits< T> :: iterator in C ++）。


（非常基本的）集数据结构，其中操作是：包含，

插入，删除和迭代，在语言标准库中存在

大多数其他语言而不是C＃。


我（我的天真）希望，有一些.NET数据结构

接口对应于某处的设置数据结构属性

in .NET ，而我还没有看到它。或者，也许某人

有一个暗示，选择向.NET用户提供我的设置的最佳方式

并非毫无疑问地知道set''的显式表示我的库里有
。


现在，我选择在我自己的命名空间中定义ISet：ICollection，

但是它可以转换为IList。


所以：

- 那些了解ISet接口的人可以使用

包含，插入和删除opreations。

- 那些不知道ISet的人可以：

- 用它作为ICollection

- 把它投到一个（非常表现不佳）IList


当然，任何用户都可以随时复制 - 构建如果他们希望使用（例如）新的ArrayList（set）的

ISet的可索引副本，那么来自我的ISet的

ICollection接口的IList;但是我不想用数百万节点网络来做

:)


-

Helge

Cooperation problems would not stem from clashing of names.

In C# (and JAVA, python, C++, ...) there are interface definition for
the most common datastructures.

This establishes a uniformity of interface for differing libraries: I
can pass an IDictionary from one independant library to another. So
datastructures with the same properties would be useable across libraries.

It becomes natural for libraries to choose the language-supplied
interface for communicating datastructures that matches these interfaces
(IDictionary, IList, Enumerator in C# -- Set, Map, Iterator ... in JAVA
-- std::set<T>, std::map<T,R>, std::iterator_traits<T>::iterator in C++).

The (very basic) set datastructure, whose operations are: contains,
insert, remove and iteration, have language-standard-library presence in
most other languages than C#.

I was (in my naivity) hoping, that there was some .NET data-structure
interface corresponding to the set data-structure properties somewhere
in .NET, and that I had just not seen it. Alternately, perhaps someone
has a hint as to the best way to choose to present my set to .NET users
not nessesarily having knowledge of the explicit representation of set''s
in my library.

For now, I have chosen to define ISet: ICollection in my own namespace,
but having it convertible to IList.

So:
- those having knowledge of the ISet interface can use the
Contains,Insert and Delete opreations.
- those not knowing the ISet can either of:
- use it as ICollection
- cast it to a (very badly performing) IList

Of course, any user can always "copy-contruct" an IList from the
ICollection interface of my ISet if they wish an indexable copy of the
ISet, using (for example) new ArrayList(set); But i wouldn''t want to do
that with the multi-million node networks :)

--
Helge

你有什么理由不使用HashTable系列，而不是基本的

IList？

-

--- Nick Malik [微软]

MCSD，CFPS，认证Scrummaster
http://blogs.msdn.com/nickmalik


免责声明：本论坛发表的意见均为我的意见拥有，而不是

代表我的雇主。

我不代表我的雇主回答问题。我只是一个帮助程序员的
程序员。

-

" Helge Jensen" <他********** @ slog.dk>在消息中写道

新闻：41 ************** @ slog.dk ...

Is there some reason you don''t use a HashTable collection, instead of basic
IList?
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I''m just a
programmer helping programmers.
--
"Helge Jensen" <he**********@slog.dk> wrote in message
news:41**************@slog.dk...

Nick Malik [微软]写道：

Nick Malik [Microsoft] wrote:

我想我没有看到从IList派生的问题，或者至少
，

I guess I''m not seeing the problem with deriving from IList or, at least,

创建一个集合只包含IList对象并且不公开其接口的对象。
IList的基本属性是自然数的可索引性，
0，...，list.Count。

我正在高效地表示网络，插入，删除
并且会员资格必须非常有效。决定节点的平等性可能相当昂贵，但是存在良好的哈希函数

creating a Set object that simply contains an IList object and doesn''t
expose its interfaces.
The basic property of IList is indexability by the natural numbers,
0,...,list.Count.

I am doing an efficient representation of networks, insertion, deletion
and membership must be decidable very efficiently. Equality can be
rather expensive to decide for the nodes, but a good hasing function

。
最佳方法（基于网络中的实际数据） ）是使用
哈希，它给我（摊销最坏情况）O（1）操作所有这些操作，其中最多1-2等于操作将完成。
<使用排序列表将产生（最坏情况）O（logN） - 用于
成员资格和（最坏情况）O（n）插入和删除操作（移动所有其他元素）虽然排序列表解决方案会为我提供一个数据结构来适应现有的System.Collections界面，但这对性能来说是一个相当糟糕的举动。 ...特别是因为我没有任何实际用于索引，仅用于遏制，插入和删除。

因此，底层数据结构只能实现索引
操作（this [int i] {get;}）迭代所有元素，计为如果我定义自己的ISet，我将介绍所有问题。 />与其他库的合作，这将使用Set
接口的其他名称。

exists.
The best approach (based on the actual data in the network) is to use
hashing, which gives me (amortized worst-case) O(1) operation on all
these operations, where at most 1-2 equals operations would get done.

Using a sorted list would yield (worst-case) O(logN)-operation for
membership and (worst-case) O(n) insert and delete operations (moving
all the other elements).

While the sorted-list solution would provide me with a data-structure to
fit an existsing System.Collections interface, it would be a rather bad
move for performance... especially since I don''t have any real use for
the indexing, only for containment, insert and delete.

So, the underlying data-structure can only implement the indexing
operation (this[int i] { get; }) by iterating all elements, counting as
it goes along. It would be a very bad idea for me to give users the
impression that my data-structure should be used as a IList.
If i define my own ISet, I will introduce all the problems of
cooperation with other libraries, which will use other names for the Set
interface.

你有没有理由相信你的命名空间不会

Is there any reason that you believe that your namespace wouldn''t take

关心任何问题与其他图书馆合作？

care of any "problems" with cooperation with other libraries?

合作问题不会源于名字的冲突。

在C＃（以及JAVA，python，C ++，...）最常见的数据结构有接口定义。

这为不同的库建立了一致的接口：我可以将IDictionary从一个独立的库传递到另一个独立的库。因此，具有相同属性的数据结构可以跨库使用。

库自然选择语言提供的接口来传递与这些接口匹配的数据结构（IDictionary，IList，C＃中的枚举器 - JAVA中的Set，Map，Iterator ...
- std :: set< T>，std :: map< T，R> ;,std :: iterator_traits<在C ++中的T> :: iterator。

（非常基本的）集数据结构，其操作是：包含，插入，删除和迭代，在<中存在语言标准库大多数其他语言而不是C＃。

我（我的天真）希望，有一些.NET数据结构接口对应于某处的设置数据结构属性<在.NET中，我还没有看到它。或者，也许某人有一个暗示，选择向.NET用户提供我的设置的最佳方式
我不知道在我的图书馆中明确表示集合'
。

目前，我选择在我自己的命名空间中定义ISet：ICollection，
但是可以将其转换为IList。

所以：
- 那些了解ISet界面的人可以使用
包含，插入和删除操作。
- 那些不了解ISet的人可以：
- 将其用作ICollection
- 将它投射到（非常糟糕的）IList

当然，任何用户都可以随时复制 - 构建来自我的ISet的ICollection接口的IList，如果他们希望使用（例如）新的ArrayList（set）的
ISet的可索引副本;但是我不想用数百万个节点网络来做这个。

-
Helge

Cooperation problems would not stem from clashing of names.

In C# (and JAVA, python, C++, ...) there are interface definition for
the most common datastructures.

This establishes a uniformity of interface for differing libraries: I
can pass an IDictionary from one independant library to another. So
datastructures with the same properties would be useable across libraries.

It becomes natural for libraries to choose the language-supplied
interface for communicating datastructures that matches these interfaces
(IDictionary, IList, Enumerator in C# -- Set, Map, Iterator ... in JAVA
-- std::set<T>, std::map<T,R>, std::iterator_traits<T>::iterator in C++).

The (very basic) set datastructure, whose operations are: contains,
insert, remove and iteration, have language-standard-library presence in
most other languages than C#.

I was (in my naivity) hoping, that there was some .NET data-structure
interface corresponding to the set data-structure properties somewhere
in .NET, and that I had just not seen it. Alternately, perhaps someone
has a hint as to the best way to choose to present my set to .NET users
not nessesarily having knowledge of the explicit representation of set''s
in my library.

For now, I have chosen to define ISet: ICollection in my own namespace,
but having it convertible to IList.

So:
- those having knowledge of the ISet interface can use the
Contains,Insert and Delete opreations.
- those not knowing the ISet can either of:
- use it as ICollection
- cast it to a (very badly performing) IList

Of course, any user can always "copy-contruct" an IList from the
ICollection interface of my ISet if they wish an indexable copy of the
ISet, using (for example) new ArrayList(set); But i wouldn''t want to do
that with the multi-million node networks :)

--
Helge

这篇关于“ISet”的界面是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！