成功的狐狸所知道的一定比刺猬所知道的总和还要多，因为它必须知道事物之间的联系。这一事实是设计用于解决某些问题的计算机系统的关键。
我经常遇到具有以下结构的域：
人们希望解决一个大型、复杂的问题，该问题符合某种统一的形式主义（例如，将汽车作为一个由10000个ODE组成的系统进行详细模拟）。
形式主义有多种方法，用于解决形式主义中所述的问题（例如，各种积分器）。这些方法是刺猬，因为它们统一处理整个问题，可能具有对整个解决方案全局的状态（例如步长）。
这个问题规模大，有许多不同的部分，具有不同的解决方案特征（例如，一些变量变化缓慢平稳，其他变量快速振荡）。
每个刺猬方法在整个问题上的表现取决于它在问题最坏部分的表现（例如，步长必须足够小，以跟踪模型中的最高频率振荡）。
不同的方法（以及全局状态的不同设置）有不同的缺点（例如，高阶积分器适合非常平滑的系统，因为它们可以实现较大的步长）。
因此，像狐狸一样解决这样的大问题是可取的：将大问题划分为更小的子问题，这些子问题在解决特征上更加一致，并用最合适的方法解决每个部分。
一方面，这种狡猾的划分得到了缓解，因为这些问题往往是稀疏的，并且有自然的派系，派系内的变量之间的相互作用比不同派系中的变量之间更为强烈和密集。
另一方面，分区很困难，因为各部分确实相互作用，所以求解方法需要在求解过程中相互传递部分或近似解。跨方法沟通尤其困难，因为每种方法都有自己的不变量，即在其发展过程中与自身沟通的内容和方式，而且作为一只刺猬，不理解其他刺猬方法的沟通。因此，翻译是必要的。
这种模式似乎经常出现在计算科学的前沿。遇到这种现象的一些形式，以及一些示例问题：
常微分方程组或微分代数方程组（以汽车为例，部分刚度相差很大）。
耦合偏微分方程（例如，通过管道、水池和储罐系统的水+温度流的详细模拟：足够窄的管道可以用1D PDE建模，足够浅的水池可以用2D PDE建模以及带有3D PDE的储罐）。
机器学习中的模型推理（不同的模型形状，如高斯混合和HMM，很容易出现在同一个复合模型中）。
- 概率编程语言的兴起加剧了这一点，概率编程语言很容易生成具有长链确定性关联变量的模型，这是穷举搜索作为推理方法的唯一亮点。
约束满足
一个常见的理论线索是，所有这些问题域都至少是NP-hard。这意味着这些问题在一般情况下是无法解决的（除非P=NP），这就是为什么每个刺猬都有弱点。当然，这也意味着任何fox-any方法组合，或任何用于选择方法的系统，在某些情况下也必须失败（除非P=NP）。然而，许多感兴趣的特殊情况是可以解决的；而切削刃出现在只能通过复合方法而不是通过统一应用基本方法来解决的地方。
因此，人们希望开发出灵活的计算机系统：能够将问题简单地（并且在可能的情况下，自动地）划分为适当的部分，选择解决部分的方法，并将其组合成解决整个问题的复合方法。
怎么到品种一数字福克斯
如何开发这样的数字狐狸？在我看来，这样的系统必须具有以下几部分：
问题语言：用于指定问题类实例的语言（例如，DAE的Modelica语言，各种概率编程语言）。
- 这种语言必须有抽象的手段，以便问题实例的人类作者能够处理他们指定的问题的复杂性（例如，一个人不会在一个大表中全部写出10000个ODE）。这些抽象边界是否总是与将问题划分为多个部分的理想划分相同？如果没有，应该如何指定或暗示分区？
刺猬：原始解方法库（例如，四阶龙格库塔、吉布斯采样）。我不知道这些库在多大程度上已经作为可重用软件存在于每个领域。然而，“方法”的定义是，实践者在经过适当的研究后，知道如何实现该方法的一个实例，该实例专门用于他们希望使用该方法解决的任何特定问题。这里的诀窍是将这些知识提取到软件定义中，这些定义指定了足够的方法来自动构建有效的专门化，但不要过度限制适用性。
桥：解决方案方法之间通信的桥库。在我看来，这是迄今为止我见过的所有狐狸中缺失的关键部分在下面特别是，我没有看到任何证据表明使这个图书馆出现在任何领域的文献中所需的知识，我也不知道这些知识在哪些领域存在，甚至在从业者的心目中也是如此。
计划语言：用于指定特定于问题的复合方法的语言。特定于问题的复合方法的规范是将问题分解为多个部分，规范用于解决每个部分的方法，以及规范用于它们之间通信的桥梁。复合方法可以具有递归结构，即用于解决部分问题的方法本身可以是复合的。这一部分也有点棘手，因为人们希望灵活处理动态问题结构（例如，中餐厅流程在解决方案运行时引入更多变量，或者ODE模拟中的条件触发器改变适用的方程）。
计划执行者：有效执行特定问题的复合解决方案方法的机制。我认为这将是查询规划器、编译器和运行时系统的某种组合，可能使用分析信息等。这种机制越好，编写基本方法和桥的库的任务就越容易（系统越能自己理解，就越不需要指定），而不那么麻烦的语言则成为复合方法的语言。
计划者：一个子系统，用于根据问题规范自动评估、搜索、建议或推断复合方法。
虽然这六个部分不同很重要，并且负责不同的工作，但我担心，除了规划师这一明显的例外，它们必须基本上是一起发明的。刺猬是什么大概一开始就知道了，但如何指定或实现它们，关键取决于执行者和桥梁。显然，这些桥梁主要依赖于它们架桥的刺猬。计划语言的设计取决于刺猬施加的构图约束和桥梁的质量，以及它需要告诉执行者多少。计划语言的设计也对刺猬和桥梁产生了反向影响。问题语言与计划语言紧密相连，因为他们都谈论同一件事的不同观点。相反，执行者取决于它将执行什么。这五个基本部分都很复杂，所以应该迭代设计。这正是一种紧密的设计依赖关系，既不应仓促进行，也不应在组织间进行划分，而应依赖于一个紧密团结的团队，该团队有足够的时间对所有部分进行迭代，直到出现一个好的解决方案。
你会注意到我在前面的警告中省略了这个计划。我认为计划者是可选的，因为没有计划者的数字狐狸已经非常有用了：与其用C++编程解决问题，实践者可以用计划者语言编程；即使没有任何进一步的援助，我预计生产率也会大幅提高。
事实上，我认为自动方法发明问题是一种转移注意力的方法。它对那些打算建造狐狸的人来说很有吸引力，因为它看起来就像狐狸要解决的问题，所以他们很想应用他们喜欢的学科方法来尝试解决它。然而，方法发明问题通常是难以解决的（除非P=NP），因为基本问题通常是难解决的。更糟糕的是，实现这一步骤自动化的希望可能导致计划语言的设计晦涩难懂，难以使用；如果规划师发明了一个糟糕的计划，这将把整个系统变成可用性噩梦。因此，我认为，努力最好是把其他部分做好；并且，在更好地理解了该领域中方法发明问题的性质之后，对其余部分进行清晰的设计将使规划师能够对工作fox进行改造。是的，这样做可能需要修改执行者，使其执行文书，并对计划的质量给出反馈，但这似乎并不是一个太高的代价，因为在制定其他五个部分时，不必太认真地考虑规划师。
顺便说一句，我认为制作数字狐狸是一种失败。从某种意义上说，对该领域的所有理解都包含在可用的刺猬中；将它们组合成一个fox会带来巨大的额外复杂性，从而无法获得“基本”的覆盖率。这不仅是实现的复杂性（已经够糟了），也是接口的复杂性：fox可能会以其组件方法失败的任何方式失败，也可能以方法选择和方法组合引入的其他方式失败。所以，如果你能在万不得已的情况下养一只狐狸，那么最好用一只更好的刺猬来解决你的问题。但是新的刺猬很难发明，当一块田地放弃并开始考虑狐狸的时候。好的一面是，一只高质量的狐狸应该能够在新的刺猬从巢穴中出来时捕捉到它们。
打开桥梁
使某个过程成为（刺猬）解方法的原因是它建立并使用一些不变量来表示问题的部分或近似解，并对其进行迭代扩展或改进。一般来说，对于任何两个不同的刺猬来说，不变量，甚至它们传递的信息都是不同的。为了将多个方法缝合在一起，则需要调整一个方法生成的供另一个方法使用的信息；如果解决方案中的信息流是双向的，则可能是双向的。
这个问题有简单版本和困难版本。当两种方法确实需要相同的信息才能在链接中流动时，就会出现简单的版本，而由于实现这些方法的软件中出现内部表示意外，这些信息恰好需要某种格式转换。通过在一个公共基板上实现所有方法，并为相同类型的信息提供通用的表示选项，可能可以消除这个问题。硬版本是当方法实际需要不同的信息时：例如，处理边际分布的推理方法使用不同于处理样本的信息。然而，由于这两种方法最终都是关于概率的，因此有希望建立一个明确的桥梁，将一种方法产生的信息近似地转换为另一种方法消耗的信息。
我可以设想两种桥梁：一种是在信息流结构中跨链接操作的桥梁，跨链接与不同方法进行通信；以及在一个节点上操作的，协调不同类型的重叠信息。在常微分方程域中，链接型桥是一种使用方程的方法，其中一些变量由一个积分器专门积分，另一些由另一个积分器积分，以在它们之间交换适当的信息。相反，如果我们允许不同方法集成的变量集重叠，则会出现节点类型桥，这是一种协调不同方法为同一变量生成的不同值的方法，并通过协调结果在积分器之间传递信息。我认为，结合链接类型和节点类型方面的混合桥也可能实现。
我的理解是，桥梁建设目前还没有得到很好的理解。我听说有传言说，进行大型模拟（ODE、PDE等）的人往往会实现这样的桥梁，显然是以一种特殊的方式来解决每个问题。但至少有原则上如何做到这一点的知识。我不知道对于机器学习问题是否存在这样的知识——有人成功地攻击了一个复合ML模型，比如说，使用MCMC推断一个部分，使用变分方法推断另一个部分吗？
现存的狐狸
当我开始写这篇文章时，我认为我不知道有什么数字狐狸，但回想起来，好的旧关系数据库管理系统很适合：SQL与数据模式、索引和表统计一起构成了问题语言；有许多不同类型的表扫描、索引搜索和结果数据结构可用于执行部分查询；查询计划语言（可以通过SQL EXPLAIN语句读取）指定特定于问题的复合方法；而查询规划器是可选的部分，它可以自动搜索计划空间中的优秀候选项。
操作系统内核似乎稍微扩展了类比，但它确实具有管理多个不同的刺猬（进程）、中介它们之间的通信（信号、管道、套接字、文件）以及判定资源使用（CPU、屏幕、键盘、网卡）的基本特征。不过，要解决的明确问题较少，方法选择也相当手动，所以我不知道Linux在这个意义上是否是一只狐狸。
对于数学倾向捆这是我所知道的唯一一个关于狐狸数学结构的例子。粘合公理类似于所有重要的桥梁。
笔记