Questions tagged «abstract-data-types»

8
是否每个数据类型都可以归结为带有指针的节点?
数组或向量只是一系列值。它们肯定可以通过链表实现。这只是一堆带有指向下一个节点的指针的节点。 堆栈和队列是Intro CS课程中通常教授的两种抽象数据类型。在课堂上的某个地方,学生通常不得不使用链接列表作为基础数据结构来实现堆栈和队列,这意味着我们回到了相同的“节点集合”的想法。 可以使用堆创建优先级队列。堆可以看作是一棵以最小值为根的树。各种树(包括BST,AVL,堆)都可以看作是由边连接的节点的集合。这些节点链接在一起,其中一个节点指向另一个节点。 似乎每个数据概念总是可以归结为仅带有指向其他某个适当节点的指针的节点。那正确吗?如果这么简单,为什么教科书不解释数据仅仅是一堆带有指针的节点呢?我们如何从节点转到二进制代码?

2
抽象数据结构和具体数据结构有什么区别?
我以为关联数组(即地图或字典)和哈希表是相同的概念,直到我在Wikipedia中看到 对于绑定数量很少的字典,使用关联列表(绑定的链接列表)来实现字典可能是有意义的。... 关联数组最常用的通用实现是使用哈希表:绑定数组,以及将每个可能的键映射到数组索引的哈希函数。... 字典也可以存储在二进制搜索树中或专用于特定类型键的数据结构中,例如基数树,try,Judy数组或van Emde Boas树。... 因此,我想,我的问题在于我不知道关联数组(即地图或字典)是一种抽象数据类型,而哈希表是一种具体的数据结构,并且可以使用不同的具体数据结构来实现相同的抽象数据类型。 我的问题是 抽象数据结构和具体数据结构之间有什么区别和关系? 每个示例都有哪些示例(抽象和具体的数据结构)?越多越好。 有哪些具体数据结构可用于实现哪些抽象数据结构的列表?拥有一个会很好。

3
一个高效的数据结构,支持Insert,Delete和MostFrequent
假设我们有一组DDD和的每个成员DDD是数据和密钥对。我们需要一个支持以下操作的数据结构: 将(d,k)(d,k)(d,k)插入DDD, 删除成员eee,(无需搜索以找到eee,例如eee指向的成员DDD), MostFrequent,它返回一个构件e∈De∈De \in D使得e.keye.keye.key是最常用的键之一DDD(请注意,最常用的键不需要唯一)。 什么是该数据结构的有效实现? 我的解决方案是为键及其频率按频率分配优先级的堆,再加上一个哈希表,在哈希表中,哈希函数将具有相同键的成员映射到哈希表中的同一插槽(指针从每个部分指向另一个部分)。 这可以使Θ(lgn)Θ(lg⁡n)\Theta(\lg n)对于前两个操作和Θ(1)Θ(1)\Theta(1)用于第三(最坏情况的运行时间)。 我想知道是否有更有效的解决方案?(或具有相同效率的更简单解决方案?)

3
抽象数据类型和对象之间有什么区别?
关于Programmers.SE的答案描述了Cook的一篇论文(对象不是ADT)说的是 对象在类型的值上表现得像特征函数,而不是代数。对象使用过程抽象而不是类型抽象 ADT通常在程序中具有唯一的实现。当某人的语言具有模块时,可以实现ADT的多种实现,但通常不能互操作。 在我看来,在库克的论文中,恰好是这样一种情况:对于库克论文中使用的集合的特定示例,可以将一个对象视为特征函数。我不认为对象通常可以视为特征函数。 另外,Aldritch的论文互操作性的力量:为什么对象不可避免 ¹暗示了 Cook的定义实质上将动态调度识别为对象的最重要特征 同意这一点,并同意艾伦·凯说的话 对我来说,OOP意味着仅消息传递,本地保留和保护以及状态过程的隐藏以及所有事物的极端后期绑定。 但是,这些伴随 Aldritch论文的演讲幻灯片表明,Java 类是ADT,而Java接口是对象-的确,使用接口“对象”可以互操作(如上面的要点之一所述,OOP的主要功能之一) )。 我的问题是 我是否正确地说特征函数不是对象的关键特征,而弗兰克·希亚尔(Frank Shearar)错误呢? 即使对象不使用动态分派,数据是否仍通过Java接口的对象示例相互通信?为什么?(我的理解是动态调度更加灵活,并且接口是迈向目标C / smalltalk / erlang样式消息传递的一步。) 依赖倒置原理的思想是否与ADT和对象之间的区别有关?(请参阅Wikipedia页面或The Talking Objects:有关面向消息的编程的故事)尽管我是这个概念的新手,但我了解它涉及在程序的“各层”之间添加接口(请参阅Wikipedia页面图)。 如果需要,请提供其他示例/说明,以区分对象和ADT。 ¹ 本文(于2013年出版)易于阅读,并以Java实例总结了Cook的2009年论文。我强烈建议至少略读一下,不要回答这个问题,而只是因为它是一篇好论文。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.