关于封装设计的性能和可扩展性，最好是：
- …“重载”函数名称（让 Mathematica 根据模式/条件/测试以及系统对定义的排序方式来确定要使用哪个版本）？
- ...或者使用 Switch[] （或类似命令）构建单个函数来直接求值？
Mathematica 的表达能力经常让我对诸如此类的愚蠢（？）问题感到困惑。
这是一个广泛的问题，但我会借此机会给出一个广泛的答案......
我主张人们应该拥抱编程语言的主要范式，而不是试图与之抗争或编写遵循另一种语言的习惯用法的代码。 Mathematica 是围绕模式匹配的概念构建的，因此，恕我直言，我们在尝试表达自己时应该始终首先考虑模式匹配。遵循这一原则，我更倾向于定义而不是Switch.
关于性能问题，在比较 Mathematica 结构时越来越强调微基准，这让我越来越烦恼。虽然了解与构造相关的成本很有价值，但我们应该留意 Knuth（或者是 Hoare？）：“我们应该忘记小的效率，比如说 97% 的时间：过早的优化是万恶之源”。 “邪恶”是程序中可读性的丧失，为了提高效率，使用一些晦涩或间接的方法来达到效果。这是我的绩效清单：
性能有问题吗？如果没有，则跳过清单的其余部分。
性能瓶颈在哪里？分析器在这里会有所帮助，但通常可以通过检查或一些打印语句轻松找到瓶颈。然后...
算法效率低下吗？非常常见的是：是否存在可以线性化或通过索引方案帮助解决的双重嵌套循环？
好的，算法很好，所以我想是时候进行微基准测试了。
我不知道我对 Mathematica 的使用是否不够雄心勃勃，但大多数时候我都没有完成第一步。然后#3 捕获了其余的大部分。在 Mathematica 中，我发现我通常只是欣喜若狂，因为我可以用少量代码执行一些雄心勃勃的任务 - 整体性能通常不会进入画面。
呃哦，我最好把肥皂盒收起来。对此感到抱歉。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
