要比速度的话，应该没有哪个好玩的字典树快。

这个表的问题在于，空间浪费，我读取的那个文本中有9682个单词，但是竟然有16883个空间没有被散列到，也就是说，只用到了4428个空间。

散列函数我还得继续修改。

简单的修改之后，冲突减少了很多，未被散列到的空间也明显减少。

感觉好玩的可以试试把哈希表和树的结构结合上来~哈希表相当于一个过滤器~然后冲突采取平衡树结构处理~这样即使是最大冲突情况下也会退化成一颗树而不是线性表~

哈希表结构的使用有很大技巧~比较理想的哈希表不是没有发生冲突(只要数据长度没有限制就有发生冲突的可能)~而是在于查找长度的平均大小~个人认为空间和时间达到平衡点的哈希表是最为理想的~

可以试试对哈希表进行压缩或者扩容以便适应于不定规模的查找~不过这样在扩容调整所需要的时间就比较慢了~而且这似乎不适用于随机数列~

当然随机数列可以预先写入文本文件或者数据库里面~这样可以利用外部资源空间进行缓冲~

[此贴子已经被作者于2017-6-14 22:56编辑过]

那倒不用，散列函数修改之后，冲突明显减少，节点数平均在2至3，所以寻找目标字符串很快。

发生冲突的可能是 22%，还是太多了。

[此贴子已经被作者于2017-6-14 23:01编辑过]

随机数列也就256个，对比其他的，显得微不足道。

散列表的核心在散列函数，第一是快，第二是生成的Key要尽可能的少冲突。

随机数列可以让散列值分布更平均（经验表明）

[此贴子已经被作者于2017-6-14 23:10编辑过]

动态散列表，要实现起来并不困难。
难点在于，如果要扩充的话，那么就需要再散列，这要用很多时间。

[此贴子已经被作者于2017-6-14 23:06编辑过]

其实一个唯一的字符串可以理解成一个量化的索引值~其实用树来处理的可以减少查找空间~如果要实用性和人性化的话对冲突用随机伸展树这样感觉比平衡树更为理想~哈希和树的区别感觉就是哈希有多个查找接口的~是一种宏观查找方法~而树相对于是一种分部查找~在查找时间上哈希一般比树要快~在空间优化上一般树的利用率比哈希要高~

在发生冲突的情况下~如果对用户查找单词频率进行优先级统计这样感觉比较理想~伸展树就可以做到~

伸展树的节点旋转，那更麻烦，如果要查找的字符串在底层，那么就需要从底层开始一直往上旋转，但是这样造成另外的麻烦就是原来的根节点被旋转到了最底层，因此如果对这个底层字符串进行查找，又需要重复的旋转过程。

对伸展树的分析很麻烦，效率如何……不好说。

[此贴子已经被作者于2017-6-14 23:21编辑过]

不过哈希加伸展树这个其实顶多自己生成数据比自己玩玩~其实如果是一些网上公用的现成的查找数据集合一般是不会有太大的查找冲突的~感觉如果要生成一个现成的哈希表一般会通过调整哈希函数来把哈希冲突减少最低~这需要额外的操作时间~

[此贴子已经被作者于2017-6-14 23:22编辑过]

其实散列表的大小对于现在的电脑而言，并不是主要问题。

问题还是在散列函数的效率。

树，我已经跳过了，树设计到的东西太多，只能通过时间来继续，绝对不是强行理解就可以的（现在的理解）。