动态解析器/预生成空间/时间权衡考虑答案

【问题标题】：On-the-fly parser/pre-generation space/time tradeoff considerations动态解析器/预生成空间/时间权衡考虑
【发布时间】：2011-08-26 09:06:08
【问题描述】：

使用动态解析器在空间方面的好处是否超过了预先生成的查找表在时间方面的好处？

加长版：

我正在创作一个化学参考工具，并包含一个功能，可以自动命名符合特定模式的公式；例如C[n]H[2n+2] => [n]ane;其中[n] 是 LHS 的整数；以及 RHS 上名称数组的索引。 (meth, eth, ...)

据我所知，这可以通过以下两种方式之一实现：

我预先生成了formula <=> name 对的键/值双重查找字典；应用程序启动时（启动速度较慢），或随应用程序发布的静态列表（下载速度较慢）。
由定制的解析器动态评估公式。

在方法 1. 中，名称 => 公式查找变得简单了一个数量级；但是生成器将，除非我想用应用程序传送几十兆字节的数据，否则必须有一个预设的相当低的 n 值。

公式可以有多个术语。如C[n]H[2n+1]OC[n']H[2n'+1]；对于这些中的每一个，可能的匹配数量会随着n 而呈几何级数增加。此外，使用这种方法会像没人管一样吃掉 RAM。

方法 2. 让我可以使用相当小的查找表支持相当大的 n 值，但会使 name => 公式查找更加复杂。与与应用程序一起交付的预生成文件相比，它还可以让我纠正生成逻辑中的错误，而无需交付新的数据文件。

这也要求每个公式都与几个规则的粗略测试相匹配，以确定它是否可以匹配；如果有很多规则，这可能会导致界面明显变慢。

那么问题来了：

在权衡中是否有任何我没有考虑到的考虑因素，或者我没有考虑过的方法？
使用动态解析器的好处是否证明了增加的实现复杂性？

【问题讨论】：

标签： language-agnostic user-experience chemistry tradeoff

【解决方案1】：

你应该采用第二种方法。

一种可能的解决方案是贪心算法。将您的转换集定义为正则表达式（用于测试模式）和一个函数，该函数给出正则表达式匹配对象并返回转换后的字符串。

正则表达式不够强大，无法直接处理您想要的内容。相反，您必须执行以下操作：

m = re.match(r"C\[(\d+)\]H\[(\d+)]\]", formula)
if m:
    C_count, H_count = int(m.group(1)), int(m.group(2))
    match_size = len(m.group(0))
    if C_count*2+2 == H_count:
        replacement = alkane_lookup[C_count]
    elif C_count*2 == H_count:
        replacement = alkene_lookup[C_count]
    ...
    else:
        replacement = m.group(0)  # no replacement available

（加上更多其他可能性）

然后将其嵌入到如下所示的循环中：

formula = "...."
new_formula = ""
while formula:
    match_size, replacement = find_replacement(formula)
    new_formula += replacement
    formula = formula[match_size:]

（您需要处理不匹配的情况。一种可能的方法是在 find_replacement() 的末尾包含所有可能元素的列表，它只返回下一个元素并计数。）

这是一个贪心算法，它不能保证最小的解决方案。这更复杂，但由于化学家自己对正确形式有不同的想法，我不会太担心。

【讨论】：