使用嵌套槽 (#)
假设我想构造类似的东西
Array[#1^#2 == 3 &, {3, 3}]
，现在我想用变量替换“3”。我可以这样做，例如：
f[x_] := Array[#1^#2 == x &, {x, x}]
问题是：有没有办法使用 only 插槽和 & ？作为函数符号？
Suppose I want to construct something like
Array[#1^#2 == 3 &, {3, 3}]
And now I want to replace the "3" with a variable. I can do, for example:
f[x_] := Array[#1^#2 == x &, {x, x}]
The question is: Is there a way using only slots and & as the functional notation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
并不是原始问题的答案，但我注意到很多人对
#0感兴趣，所以 这里我举了几个重要的例子，希望它们有用。关于对于嵌套函数，应该使用带有命名参数的函数的说法：虽然这通常是正确的，但人们应该始终记住，纯函数的词法作用域（通常）是在 Mathematica 中模拟的，并且可以被破坏。示例：
此行为与规则替换的侵入性有关 - 也就是说，
Rule和RuleDelayed不关心以下名称之间可能的名称冲突：范围构造可能出现在受规则应用约束的表达式中，以及规则中模式变量的名称。更糟糕的是，g和f单独使用时完全可以正常工作。当它们混合在一起时，就会发生这种纠缠，并且只是因为我们不幸在f的主体中使用相同的模式变量x，就像在纯功能。这使得此类错误非常难以捕获，而这种情况在实践中有时确实会发生，因此我建议不要将带有命名参数作为参数的纯函数传递到通过模式定义的高阶函数中。编辑：
稍微扩展一下词法范围的模拟。我的意思是，例如，当我创建一个纯函数（这是一个词法作用域构造，将其主体中的变量名称绑定到传递参数的值）时，我希望我不应该能够更改此绑定在我创建了一个函数之后。这意味着，无论我在哪里使用 Function[x,body-that-depends-on-x]，我都应该能够将其视为带有输入参数和结果输出的黑匣子。但是，在 Mathematica 中，
Function[x,x^2]（例如）也是一个表达式，因此可以像任何其他表达式一样进行修改。例如：或者，更简单（我之前警告的本质）：
我被最后一种行为咬了好几次，非常痛苦。 @WReach 在他关于这个页面——显然他也有类似的经历。基于对 Mathematica 在冲突期间如何重命名变量的确切了解，还有其他方法可以打破范围，但这些方法在实践中危害相对较小。一般来说，我认为如果坚持 Mathematica 表达式所代表的透明度水平，这些事情是无法避免的。对于纯函数（以及一般的词法作用域构造）来说，它似乎“过于透明”，但另一方面，这也有它的用途，例如我们可以在运行时伪造一个纯函数，如下所示
：积分仅在定义时计算一次（也可以使用
Evaluate）。所以，这看起来像是一个权衡。通过这种方式，函数抽象可以更好地集成到 Mathematica 中，但正如@WReach 指出的那样，存在漏洞。或者，它也可以是“防水的”，但代价可能是减少暴露。这显然是一个设计决定。Not really the answer to the original question, but I noticed that many people got interested in
#0stuff, so here I put a couple of non-trivial examples, hope they will be useful.Regarding the statement that for nested functions one should use functions with named arguments: while this is generally true, one should always keep in mind that lexical scoping for pure functions (and generally) is emulated in Mathematica, and can be broken. Example:
This behavior has to do with the intrusive nature of rule substitutions - that is, with the fact that
RuleandRuleDelayeddon't care about possible name collisions between names in scoping constructs which may be present in expressions subject to rule applications, and names of pattern variables in rules. What makes things worse is thatgandfwork completely fine when taken separately. It is when they are mixed together, that this entanglement happens, and only because we were unlucky to use the same pattern variablexin the body off, as in a pure function. This makes such bugs very hard to catch, while such situations do happen sometimes in practice, so I'd recommend against passing pure functions with named arguments as parameters into higher-order functions defined through patterns.Edit:
Expanding a bit on emulation of the lexical scoping. What I mean is that, for example, when I create a pure function (which is a lexical scoping construct that binds the variable names in its body to the values of passed parameters), I expect that I should not be able to alter this binding after I have created a function. This means that, no matter where I use
Function[x,body-that-depends-on-x], I should be able to treat it as a black box with input parameters and resulting outputs. But, in Mathematica,Function[x,x^2](for instance) is also an expression, and as such, can be modified like any other expression. For example:or, even simpler (the essence of my previous warning):
I was bitten by this last behavior a few times pretty painfully. This behavior was also noted by @WReach at the bottom of his post on this page - obviously he had similar experiences. There are other ways of breaking the scope, based on exact knowledge of how Mathematica renames variables during the conflicts, but those are comparatively less harmful in practice. Generally, I don't think these sorts of things can be avoided if one insists on the level of transparency represented by Mathematica expressions. It just seems to be "over-transparent" for pure functions (and lexical scoping constructs generally), but on the other hand this has its uses as well, for example we can forge a pure function at run-time like this:
Where the integral is computed only once, at definition-time (could use
Evaluateas well). So, this looks like a tradeoff. In this way, the functional abstraction is better integrated into Mathematica, but is leaky, as @WReach noted. Alternatively, it could have been "waterproof", but perhaps for the price of being less exposed. This was clearly a design decision.可怕的丑陋元素提取怎么样
，非常有趣的是
Map[Last, #]&给了我与Last /@不同的结果。这是因为Map与&具有不同的属性吗？How about
Horrendously ugly element extraction, and very interestingly
Map[Last, #]&gives me a different result thanLast /@. Is this due to the fact thatMaphas different attributes than&?我想您知道文档中关于嵌套纯函数的内容。
无论如何，这是我在不遵循上述建议的情况下能想到的最好的方法：
< code>g 在功能上与原始
f相同，但并不比推荐的更好I guess you know what the documentation says about nested pure functions.
Anyway, here's the best I could come up with without following the above advice:
gis functionally identical to your originalf, but is not really better than the recommendedWith[{x = #1}, Array[#1^#2 == x &, {x, x}]] &怎么样？How about
With[{x = #1}, Array[#1^#2 == x &, {x, x}]] &?也许
或者
Perhaps
Or