APL 解释器如何优化每个运算符？答案

【问题标题】：How is each operator optimized by the APL interpreter?APL 解释器如何优化每个运算符？
【发布时间】：2014-08-06 12:25:28
【问题描述】：

我想知道在使用 APL 时是否应该大量使用 each 运算符，还是应该尝试为给定问题找到另一种解决方案？

如何在 APL 中优化此运算符的使用？

【问题讨论】：

除非您使用 APL 的开源实现，否则每个原语的确切内部都是依赖于供应商和黑盒的。 “每个”被认为是一个隐藏循环，但在某些情况下它可能有用。如果将 d-fn 应用于每个数组而不是整个数组，则程序可能会运行更大的输入大小，因为 d-fns 将在完成后弹出所有本地数据）

标签： apl dyalog

【解决方案1】：

而不是写类似的东西

1 +" 2 x" 3|" (1 2 3) (4 5 6)    // sorry, no apl chars

我会写

{1 + 2 x 3 | omega}" (1 2 3) (4 5 6)

或

foo" (1 2 3) (4 5 6)

其中 foo 包含计算。

换句话说，当功能可以组合时，避免链接连续的每个操作。 Dyalog DFN {...} 提供了一种很好的方式来实现这一点。

但最重要的是，我会首先尝试以最自然的方式解决问题，而不考虑是否存在运行得更快的解决方法。如果解决方案足够好，也就是说，它的性能足够好，并且您和您的同事将来某个时候能够理解它，我会不理会它。

【讨论】：

在这个特定示例中，您不需要 ¨（每个），因为 + × | 无论如何都会递归地应用于嵌套数组。
当 foo"data 调用长时间运行的操作或迭代使用自动化、.Net 或某些外部服务时，显式循环可能更适合调试。这取决于 APL 系统如何处理中断。

【解决方案2】：

在大多数情况下，each 的性能不如不使用 each 的数组解决方案，但有时它是编写复杂表达式的最简单和最清晰的方法。但是，如果有两种方法可以完成大致相同的清晰度和复杂性的任务，并且不使用每种方法，我会倾向于选择那一种。如果它很重要，当然，仪器和测量。除非这适用于相当大的数据，否则它很可能无关紧要。上面对每个用于调用长时间运行的操作或外部服务的评论是准确的。

【讨论】：