【发布时间】:2016-02-17 08:43:58
【问题描述】:
我有一个词汇表,a、abandon、...、z。
出于某种原因,我将使用数组而不是 Trie 来存储它们。
因此一个简单的方法可以是:wordA\0wordB\0wordC\0...word\0
但我认为还有一些更经济的记忆方法。
由于like是likely的子串,我们只能存储like的第一个位置和长度,而不是字符串本身。因此,我们生成了一个“大字符串”,其中包含词汇表中的每个单词,并使用position[i] 和length[i] 得到i-th 单词。
例如,词汇表包含三个单词ab、cd 和bc。
我将abcd 构造为“大字符串”。
position[0] = 0, length[0] = 2
position[1] = 2, length[1] = 2
position[2] = 1, length[2] = 2
那么如何生成“大字符串”是这个问题的关键,有什么很酷的建议吗?
我认为这个问题类似于TSP问题(Traveling Salesman Problem),属于NP问题。
【问题讨论】:
-
有什么理由不从现有的数据库解决方案中受益?当然你可以发明你自己的。但是,值得付出努力吗?
-
@clq:我认为关系数据库不会将字符串表压缩为 Trie 或任何东西。如果我错了,请纠正我,但是以单个字符串字段作为主键的 DB 表将为您提供非常快速的索引检查是否存在/不存在,但可能会占用 更多 空间而不是将它们全部存储回来-在 C 字符串中返回。
-
@clq 数组对于纯 C 项目来说更高效且易于处理。
-
@LTzycLT:空间效率更高,但时间效率低于使用开箱即用的数据库。数据库库将为您提供良好的性能,而无需花费大量开发时间。
-
trie 有什么问题?您正在谈论的结构对我来说似乎非常具有限制性……或者换一种说法:它只能在非常特定的情况下获利。你举了一个例子,其中一个词是另一个词的前缀 - “喜欢”和“可能”。但是如果他们只 share 前缀怎么办。对于即时“喜欢”和“喜欢”。你的数组应该如何有效地存储这两个词?好吧,我认为 Trie 将是完美的......
标签: arrays algorithm vocabulary