【发布时间】:2019-12-24 16:40:59
【问题描述】:
给定一个格式为{Length}.{Text}(如3.foo)的字符串,我想从有限列表中确定给定字符串是哪个字符串。
阅读器从 0 索引开始,可以向前搜索(如果需要,可以跳过字符)。
例如,考虑以下列表:
10.disconnect
7.dispose
7.distort
确定已显示哪些字符串的最短方法可能如下所示:
if (reader.Current == "1")
{
// the word is "disconnect"
}
else
{
reader.MoveForward(5);
if (reader.Current == "p")
{
// the word is "dispose"
}
else
{
// the word is "distort"
}
}
这个问题有 2 个部分,但我希望有人能指出我需要阅读更多信息的正确算法或信息论方面。
1) 给定一个有限的字符串列表,生成逻辑的最佳方法是平均需要最少次数的查找和比较来确定呈现的是哪个单词?
2) 与第一个一样,但允许加权以便可以考虑热路径。即,如果“distort”这个词比“disconnect”和“dispose”这个词的可能性高4倍,那么上面显示的逻辑如果结构如下,平均性能会更高:
reader.MoveForward(5);
if (reader.Current == "t")
{
// the word is distort
}
else //...
注意:我知道示例集中的第 6 个字符是唯一的,因此解决示例集所需要做的就是在该字符上使用 switch,但请假设有更长的列表单词。
另外,这不是家庭作业——我正在为Guacamole protocol 编写解析器/拦截层。我看过二叉树、Tries、Ulam's Game 和其他一些,但没有一个符合我的要求。
【问题讨论】:
-
是否有可能对给定的列表进行排序/排序?还是需要保持原样。
-
您可以对列表进行排序。但是,这里的目标是根据从给定列表派生的规则来设计代码(设计代码......?)。希望这是有道理的?我发现如果你删除只进规则,通过检查每个索引处的字符分布来完成这项任务(手动/手动)相当容易;分布越高,该指数越有用。前进只会让它变得更加棘手:-/
-
你的问题太宽泛了。也就是说,我认为你也找错了树。 1) 还没有人为该协议编写过解析器吗?使用现有艺术可能更有意义。 2) 你真的有性能问题吗?字符串解析不应该给计算机带来太多的任务,如果有的话。 I/O 和其他操作肯定会主导计算成本吗? ...
-
... 3) “只进”真的是这里重要的目标吗?例如,如果字符串总是采用“
. ”的形式,并且您可以选择有限的东西,我希望字典更简单、更快。 4) 如果您坚持“仅向前”策略,我认为您正在查看状态机或该主题的一些变体。 -
如果性能很重要,并且您认为您的测试表明基于字典的方法和显式实现的状态机之间存在显着差异,那么您应该只使用后者。如果您对是否可以改进基于字典的方法感到好奇,可以将其发布到 codereview.stackexchange.com。我不打算再搜索我的帖子了……旧新闻组的存档似乎不完整,而且无论如何挖掘它似乎没有多大意义。