看到算法导论的散列了...长征二万五还只行了一半不到呢.先概念一把
1、散列表
散列方法不同于顺序查找、二分查找、二叉排序树及B-树上的查找。它不以关键字的比较为基本操作,采用直接寻址技术。在理想情况下,无须任何比较就可以找到待查关键字,查找的期望时间为O(1)。
设所有可能出现的关键字集合记为U(简称全集)。实际发生(即实际存储)的关键字集合记为K(|K|比|U|小得多)。
散列方法是使用函数h将U映射到表T[0..m-1]的下标上(m=O(|U|))。这样以U中关键字为自变量,以h为函数的运算结果就是相应结点的存储地址。从而达到在O(1)时间内就可完成查找。
其中:
① h:U→{0,1,2,…,m-1} ,通常称h为散列函数(Hash Function)。散列函数h的作用是压缩待处理的下标范围,使待处理的|U|个值减少到m个值,从而降低空间开销。
② T为散列表(Hash Table)。
③ h(K
i)(K
i∈U)是关键字为K
i结点存储地址(亦称散列值或散列地址)。
④ 将结点按其关键字的散列地址存储到散列表中的过程称为散列(Hashing)
2、散列表的冲突现象
(1)冲突
两个不同的关键字,由于散列函数值相同,因而被映射到同一表位置上。该现象称为冲突(Collision)或碰撞。发生冲突的两个关键字称为该散列函数的同义词(Synonym)。
【例】上图中的k
2≠k
5,但h(k
2)=h(k
5),故k
2和K
5所在的结点的存储地址相同。
(2)安全避免冲突的条件
最理想的解决冲突的方法是安全避免冲突。要做到这一点必须满足两个条件:
①其一是|U|≤m
②其二是选择合适的散列函数。
这只适用于|U|较小,且关键字均事先已知的情况,此时经过精心设计散列函数h有可能完全避免冲突。
(3)冲突不可能完全避免
通常情况下,h是一个压缩映像。虽然|K|≤m,但|U|>m,故无论怎样设计h,也不可能完全避免冲突。因此,只能在设计h时尽可能使冲突最少。同时还需要确定解决冲突的方法,使发生冲突的同义词能够存储到表中。
(4)影响冲突的因素
冲突的频繁程度除了与h相关外,还与表的填满程度相关。
设m和n分别表示表长和表中填人的结点数,则将α=n/m定义为散列表的装填因子(Load
Factor)。α越大,表越满,冲突的机会也越大。通常取α≤1。
上网search一把,多是hash fun.至于冲突什么的,算了算了.俺不是愤青...萌生了自己动手写一整套的想法.hash函数你可以用你自己的.写好后传给hashit_create就可以了int(*cfunc)(const void *,const void *)!!!!至于冲突的解决.
union {
struct elem **chtable; /* Chain hash (ch) */
struct oaelem *oatable; /* Open Address hash (oa) */
struct ov *ov; /* Hash with overflow area (ov) */
} cm; /* Data for the various collision methods */
定义了三种,但是只实现了一种.仿照的写应该问题不大...
不过笔试的时候要让我没参考的东东,就动手写hash的话.我想我还是写不出来的.惭愧.....
这是算法导论的第一遍,第二遍的时候尽量尝试手写吧...不习惯....我是习惯了man和google的男人^_^
[root@mip-123456 hash]# ls
hash.c hashit.c hashit.h hfunctions.c hfunctions.h Makefile
[root@mip-123456 hash]# make
gcc -c -o hash.o hash.c
Compiling hashit.c... [ OK ]
Compiling hfunctions.c... [ OK ]
Generating hash... [ OK ]
[root@mip-123456 hash]# ./hash
begin...
phone=263788
phone=020-69854124
city=guangzhou
key:name
key:address
key:phone
key:door
key:city
key:sex
key:major
value:guangzhou
value:information
value:020-69854124
value:netboy
value:110#
value:male
value:china
|
文件: | hash.tar |
大小: | 60KB |
下载: | 下载 |
|
|
阅读(916) | 评论(0) | 转发(0) |