Trie树/字典树

传说中字典树能够有效地压缩数据存储量,不明就里,查阅一番。字典树在百度百科中的定义

都说效率高那就效率高吧……高效率我是可以理解的,毕竟查找的次数减少了非常多,但是对于节省内存这一项实在想不通,于是用了一个大小为2.137MB(去除换行符1.7067MB,一共19,9071个词条)的字典文件作为输入进行了测试,结果如下:

 

There are 451798 nodes and need 48794184 bits to store!

 

平均每个词条需要2.27个节点,每个词条的平均长度为8.99个字符(减掉了行尾的换行),继续平均一下,也就是每个字符0.2525个节点,每个节点16B,这样算来,和直接读入的内存比较大约为4倍 (<-被平均晕掉的直接看这里)。

 

笔者使用的节点的数据结构为:

code1-1

 

考虑到对齐的问题,一个节点的大小为108bits(26*4+2>4?2:4),这样的结果换算下来需要的内存大小是5.817MB,符合上述的分析结果。

存储空间变大了,再仔细一想,这才是钢之炼金术师的精髓啊,等价交换!!!

为了速度,空间的开销是必须的,百科上面的节省内存是相对于hash什么的(随便猜猜,这个只能问百度百科的编辑者了……)说的吧(更新一下,使用双数组可以有效的压缩内存,孤陋寡闻+夜郎自大-_-!!!传送门 ),对于直接读入内存或者用BST建立数据结构都不会使用这么大的内存开销(但是相对的,查找速度可见一斑……而且如果对于有序的词典,BST的查找绝对会让人无比蛋疼……),但是查找的耗时只和query的长度有关,这不是很美妙么~

 

因此因此,字典树用于查找字符串什么的有很好的时间性能,但是有内存开销(么有免费的午餐,绝对的真理)。

 

剩下的代码就比较简单了,贴之~

(半个小时之后……)

谁特么说删除简单来着……只想到了两种特例,现在脑子不太清楚了,删除留着明天更新,部分代码:

Code1-2(除了删除,啥都有……)

 

删除是比较麻烦,刚才去网上看了一下,有两种BT到小菜爷我都花枝乱颤的解法:

1 把对应节点的word_end置为false(这个绝对是天才啊……)

2 开一个内存堆,把什么都扔进去,到时候直接把堆删了。

 

Faint,人民的智慧真是无限的……

自己想了想,在BT解法的影响下想出了两种特例,剩下的明天解决~~

1 不存在(多么happy的特例~)

2 存在(同时具有prefix和wordEnd属性,把word_end属性置为false)

3 一般情况(待解决)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值