从 Rule 和 / 切换有什么好处？大型应用程序中的 OptionsPattern[] 和 OptionValue？

Question

旧习惯很难改掉，我意识到我一直在使用 opts___Rule 模式匹配和像 thisoption / 这样的结构。 {选择}/。我当前正在开发的非常大的包中的选项[myfunction]。 Sal Manango 的“Mathematica Cookbook”提醒我，版本 6 后执行此操作的方法是 opts:OptionsPattern[] 和 OptionValue[thisoption]。无论如何，这个包需要版本 8，但多年来我从未改变过编写此类代码的方式。

是否值得从我版本 6 之前的做事方式中重构所有这些？有性能或其他好处吗？

问候

Verbeia

编辑：总结

在回答这个问题时提出了很多好的观点，所以谢谢大家（当然还要加一）。总而言之，是的，我应该重构以使用 OptionsPattern 和 OptionValue。 （注意：OptionsPattern 不是我之前使用的 OptionPattern！）原因有很多：

1. 速度更快 (@Sasha)
2. 它可以更好地处理参数所在的函数必须在 HoldForm (@Leonid)
3. OptionsPattern 中自动检查您是否向该函数传递了有效选项（如果您是传递给不同的函数（@Leonid）
4. 它可以更好地处理RuleDelayed（：>）（@rcollyer）
5. 它可以在不使用Flatten<的情况下处理嵌套的规则列表/code> (@Andrew)
6. 使用 OptionValue /@ list 分配多个局部变量比多次调用 someoptions / 更容易。选项[thisfunction]（在@rcollyer和我之间的评论中出现）

编辑：7月25日我最初认为使用/.语法的一次可能会仍然有意义的是，如果您故意从另一个函数而不是实际被调用的函数中提取默认选项。事实证明，这是通过使用 OptionsPattern[] 的形式来处理的，其中包含一个头列表，例如： OptionsPattern[{myLineGraph, DateListPlot, myDateTicks, GraphNotesGrid}]（请参阅 文档）。我最近才解决这个问题。

Answer 1

看起来依赖模式匹配器比使用PatternTest 产生更快的执行速度，因为后者需要调用评估器。不管怎样，我的时间安排表明可以实现一些加速，但我不认为它们如此重要以至于需要进行重构。

In[7]:= f[x__, opts : OptionsPattern[NIntegrate]] := {x, 
  OptionValue[WorkingPrecision]}

In[8]:= f2[x__, opts___?OptionQ] := {x, 
  WorkingPrecision /. {opts} /. Options[NIntegrate]}

In[9]:= AbsoluteTiming[Do[f[1, 2, PrecisionGoal -> 17], {10^6}];]

Out[9]= {5.0885088, Null}

In[10]:= AbsoluteTiming[Do[f2[1, 2, PrecisionGoal -> 17], {10^6}];]

Out[10]= {8.0908090, Null}

In[11]:= f[1, 2, PrecisionGoal -> 17]

Out[11]= {1, 2, MachinePrecision}

In[12]:= f2[1, 2, PrecisionGoal -> 17]

Out[12]= {1, 2, MachinePrecision}

Answer 2

虽然几个答案都强调了新旧使用选项方式的不同方面，但我想提出一些额外的观察结果。较新的构造 OptionValue - OptionsPattern 比 OptionQ 提供更高的安全性，因为 OptionValue 检查全局选项列表确保函数已知传递的选项。然而，旧的 OptionQ 似乎更容易理解，因为它仅基于标准模式匹配，并且与任何全局属性不直接相关。您是否想要这些结构提供的额外安全性取决于您，但我的猜测是大多数人发现它很有用，特别是对于较大的项目。

这些类型检查真正有用的原因之一是，选项通常以链式方式作为参数通过函数传递、过滤等，因此如果没有这样的检查，一些模式匹配错误将很难捕获，因为它们会在远离其起源地的地方造成伤害。

就核心语言而言，OptionValue - OptionsPattern 构造是模式匹配器的补充，也许是其所有功能中最“神奇”的。只要人们愿意将选项视为规则的一种特殊情况，这在语义上就没有必要。此外，OptionValue 将模式匹配连接到Options[symbol] - 一个全局属性。因此，如果坚持语言的纯粹性，opts___?OptionQ 中的规则似乎更容易理解——除了标准的规则替换语义之外，不需要任何东西来理解这一点：（

f[a_, b_, opts___?OptionQ] := Print[someOption/.Flatten[{opts}]/.Options[f]]

我提醒一下 >OptionQ 谓词是专门为识别旧版本 Mathematica 中的选项而设计的），而 this:

f[a_, b_, opts:OptionsPattern[]] := Print[OptionValue[someOption]]

看起来很神奇。当您使用 Trace 并看到 OptionValue 的简短形式计算为较长形式时，情况会变得更清晰，但它自动确定封闭函数名称的事实仍然是卓越。

OptionsPattern 作为模式语言的一部分还会带来一些后果。一是@Sasha 讨论的速度改进。然而，速度问题常常被过分强调（这并不是为了偏离他的观察），我希望对于带有选项的函数来说尤其如此，因为这些往往是更高级别的函数，它们可能具有非琐碎的身体，大部分计算时间将花费在其中。

另一个相当有趣的区别是，当需要将选项传递给保存其参数的函数时。考虑以下示例：

ClearAll[f, ff, fff, a, b, c, d];
Options[f] = Options[ff] = {a -> 0, c -> 0};
SetAttributes[{f, ff}, HoldAll];
f[x_, y_, opts___?OptionQ] :=
   {{"Parameters:", {HoldForm[x], HoldForm[y]}}, {" options: ", {opts}}};
ff[x_, y_, opts : OptionsPattern[]] :=
   {{"Parameters:", {HoldForm[x], HoldForm[y]}}, {" options: ", {opts}}};

这没问题：

In[199]:= f[Print["*"],Print["**"],a->b,c->d]
Out[199]= {{Parameters:,{Print[*],Print[**]}},{ options: ,{a->b,c->d}}}

但是这里我们基于 OptionQ 的函数将泄漏计算作为模式匹配过程的一部分：

In[200]:= f[Print["*"],Print["**"],Print["***"],a->b,c->d]
During evaluation of In[200]:= ***
Out[200]= f[Print[*],Print[**],Print[***],a->b,c->d]

这并非完全微不足道。发生的情况是，为了确定匹配或不匹配的事实，模式匹配器必须评估第三个 Print，作为 OptionQ 评估的一部分，因为 < code>OptionQ 不包含参数。为了避免计算泄漏，需要使用 Function[opt,OptionQ[Unevaluated[opt]],HoldAll] 代替 OptionQ。使用 OptionsPattern 我们就不存在这个问题，因为匹配的事实可以纯粹从语法上建立：

In[201]:= ff[Print["*"],Print["**"],a->b,c->d]
Out[201]= {{Parameters:,{Print[*],Print[**]}},{ options: ,{a->b,c->d}}}

In[202]:= ff[Print["*"],Print["**"],Print["***"],a->b,c->d]
Out[202]= ff[Print[*],Print[**],Print[***],a->b,c->d]

所以，总结一下：我认为选择一种方法而不是另一种方法很大程度上取决于品味 - 每个方法每一项都可以被有效利用，但也都可能被滥用。我更倾向于使用新的方法，因为它提供了更多的安全性，但我不排除存在一些让您惊讶的极端情况 - 而旧的方法在语义上更容易理解。这类似于 C-C++ 比较（如果这是一个合适的比较）：自动化和（可能）安全性与简单性和纯粹性。我的两分钱。

Answer 3

一个鲜为人知（但经常有用）的事实是，允许选项出现在嵌套列表中：

In[1]:= MatchQ[{{a -> b}, c -> d}, OptionsPattern[]]

Out[1]= True

选项处理函数，例如 FilterRules 了解这一点：

In[2]:= FilterRules[{{PlotRange -> 3}, PlotStyle -> Blue, 
  MaxIterations -> 5}, Options[Plot]]

Out[2]= {PlotRange -> 3, PlotStyle -> RGBColor[0, 0, 1]}

OptionValue 接受它考虑到：

In[3]:= OptionValue[{{a -> b}, c -> d}, a]

Out[3]= b

但是ReplaceAll (/.) 当然不会考虑到这一点：

In[4]:= a /. {{a -> b}, c -> d}

During evaluation of In[4]:= ReplaceAll::rmix: Elements of {{a->b},c->d} are a mixture of lists and nonlists. >>

Out[4]= a /. {{a -> b}, c -> d}

所以，如果您使用 OptionsPattern，您可能还应该使用 OptionValue 来确保您可以使用用户传入的选项集。

另一方面，如果您使用 ReplaceAll (/.)，出于同样的原因，您应该坚持使用 opts___Rule。

请注意，opts___Rule在某些（诚然是晦涩的）情况下也有点过于宽容：

不是一个有效的选项：

In[5]:= MatchQ[Unevaluated[Rule[a]], OptionsPattern[]]

Out[5]= False

但是___Rule让它通过：

In[6]:= MatchQ[Unevaluated[Rule[a]], ___Rule]

Out[6]= True

更新：作为rcollyer 指出，___Rule的另一个更严重的问题是它错过了用规则延迟 (:>)。您可以解决它（请参阅 rcollyer 的答案），但这是使用 OptionValue 的另一个好理由。

Answer 4

您的代码本身有一个微妙但可修复的缺陷。模式 opts___Rule 不会匹配 a :>; 形式的选项。 b，因此如果您需要使用它，则必须更新代码。立即修复的方法是将 opts___Rule 替换为 opts:(___Rule | ___RuleDelayed)，这比 OptionsPattern[] 需要更多的输入。但是，对于我们当中的懒人来说，OptionValue[...] 比短形式的 ReplaceAll 需要更多的输入。但是，我认为这可以使代码阅读更清晰。

我发现使用 OptionsPattern[] 和 OptionValue 更容易阅读并立即理解正在执行的操作。旧形式的 opts___ ... 和 ReplaceAll 在第一次通读时更难理解。除此之外，明确的 时间优势，我会更新您的代码。