通过 Mathematica 的交互式树进行代码操作
这个问题让我思考一个互动问题编辑代码的方法。我想知道考虑到 Mathematica 的动态功能是否可以实现这样的东西。
考虑一个表达式：
Text[Row[{PaddedForm[currentTime, {6, 3}, NumberSigns -> {"", ""}, NumberPadding -> {"0", "0"}]}]]
及其 TreeForm:
我希望能够直接编辑该树，然后将结果转换回 Mathematica 代码。人们至少应该能够：
- 重命名节点，替换符号
- 删除节点，将它们的叶子恢复到上面的节点
- 重新排序节点和叶子（参数的顺序）
我相信有专门从事这种操作的语言或环境，并且我觉得这没有吸引力，但我对这种用于特殊目的的交互式树编辑很感兴趣。
This question caused me to ponder an interactive method for editing code. I wonder if it is possible to implement something like this given the dynamic capabilities of Mathematica.
Consider an expression:
Text[Row[{PaddedForm[currentTime, {6, 3}, NumberSigns -> {"", ""}, NumberPadding -> {"0", "0"}]}]]
And its TreeForm:
I would like to be able to edit that tree directly, and then have the result translated back into Mathematica code. One should at least be able to:
- rename nodes, replacing symbols
- delete nodes, reverting their leaves to the node above
- reorder nodes and leaves (the order of arguments)
I believe that there are languages or environments which specialize in this kind of manipulation, and I do not find that attractive, but I am interested in having this kind of interactive tree editing for special purposes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将提供部分解决方案，但可以帮助您入门。我将使用这篇文章中的可变树数据结构，因为它对于这个问题来说，可变性似乎是很自然的。为了方便起见，在这里重复一下：
下面是从任何 Mathematica 表达式创建可变树并从树中读回表达式的代码：
您可以测试像
a+b这样的简单表达式。关于其工作原理的一些评论：要从表达式创建可变表达式树（由node-s 构建），我们调用makeExpressionTree函数，该函数首先创建树（调用makeExpressionTreeAux），然后索引节点（调用indexNodes）。 makeExpressionTree 函数是递归的，它递归地遍历表达式树，同时将其结构复制到生成的可变树的结构中。这里的一个微妙之处是为什么我们需要诸如val = Hold[Evaluate[Unique[]]]、nd.setValue[val];、Evaluate[val [[1]]] = expr;而不仅仅是nd.setValue[expr]。这是在考虑到InputField[Dynamic[some-var]]的情况下完成的 - 为此，我们需要一个变量来存储值（也许，可以编写一个更自定义的Dynamic如果愿意的话可以避免这个问题）。因此，创建树后，每个节点都包含一个值Hold[someSymbol]，而someSymbol包含原子或头的值，对于非-原子子部分。索引过程将每个节点的值从Hold[sym]更改为{index,Hold[symbol]}。请注意，它使用 traverse 函数实现通用深度优先可变树遍历（类似于 Map[f,expr, Infinity]，但针对可变树）。因此，索引按深度优先顺序递增。最后，expressionFromTree函数遍历树并构建树存储的表达式。下面是渲染可变树的代码：
这部分的工作原理如下：
getGraphRules函数遍历树并收集节点索引的父子对（以规则的形式），结果集Rules 是 GraphPlot 期望的第一个参数。 getNodeIndexRules 函数遍历树并构建哈希表，其中键是节点索引，值是节点本身。makeSymbolRule函数获取节点并返回index:>node-var-symbol形式的延迟规则。延迟规则很重要，这样符号就不会计算。这用于将节点树中的符号插入到InputField[Dynamic[]]中。使用方法如下：首先创建一棵树：
然后渲染它：
您必须能够修改每个输入字段中的数据，尽管需要单击几下才能使光标出现在那里。例如，我将
c编辑为c1，将b编辑为b1。然后，您将得到修改后的表达式：该解决方案仅处理修改，但不处理节点的删除等。但是，它可以作为一个起点，并且也可以扩展以涵盖这一点。
编辑
这是一个更短的函数，基于相同的想法，但不使用可变树数据结构。
下面是如何使用它：
您可以随时调用
getExpression[]来查看表达式的当前值或将其分配给任何变量，或者您可以使用此方法产生更短的代码，因为 Mathematica原生树结构被重新用作树的骨架，其中所有信息片段（头和原子）都被符号替换。只要我们能够访问原始符号而不仅仅是它们的值，这仍然是一个可变树，但我们不需要考虑树的构建块 - 我们使用表达式结构。这并不是要削弱之前较长的解决方案，从概念上我认为它更清晰，并且对于更复杂的任务来说它可能仍然更好。
I will provide a partial solution, but the one that could get you started. I will use the mutable tree data structure from this post, since it seems like mutability is natural for this problem. Repeating it for convenience here:
Here is the code to create a mutable tree from any Mathematica expression, and read the expression back from the tree:
You can test on simple expressions like
a+b. A few comments on how this works: to create a mutable expression tree (built ofnode-s) from an expression, we call themakeExpressionTreefunction, which first creates the tree (call tomakeExpressionTreeAux), and then indexes the nodes (call toindexNodes). ThemakeExpressionTreefunction is recursive, it recursively traverses the expression tree while copying its structure to the structure of the resulting mutable tree. One subtle point here is why we need things likeval = Hold[Evaluate[Unique[]]],nd.setValue[val];,Evaluate[val[[1]]] = expr;rather than justnd.setValue[expr]. This is done withInputField[Dynamic[some-var]]in mind - for this, we need a variable to store the value (perhaps, one could write a more customDynamicto avoid this problem if one likes). So, after the tree is created, each node contains a value that isHold[someSymbol], whilesomeSymbolcontains the value of an atom, or of a head, for non-atomic sub-part. The indexing procedure changes the value of each node fromHold[sym]to{index,Hold[symbol]}. Note that it uses thetraversefunction which implements the generic depth-first mutable tree traversal (similar toMap[f,expr, Infinity], but for mutable trees). Therefore, indexes are incremented in depth-first order. Finally, theexpressionFromTreefunction traverses the tree and builds the expression that the tree stores.Here is the code to render the mutable tree:
This part works as follows: the
getGraphRulesfunction traverses the tree and collects parent-child pares of node indices (in the form of rules), the resulting set of rules is what theGraphPlotexpects as a first argument. ThegetNodeIndexRulesfunction traverses the tree and builds the hash table where keys are node indices and values are the nodes themselves. ThemakeSymbolRulefunction takes the node and returns the delayed rule of the formindex:>node-var-symbol. It is important that the rule is delayed, so that the symbols do not evaluate. This is used to insert the symbol from the node tree intoInputField[Dynamic[]].Here is how you can use it: first create a tree:
Then render it:
You must be able to modify data in each input field, although it takes a few clicks to make the cursor appear there. For example, I edited
cto bec1andbto beb1. Then, you get the modified expression:This solution handles only modifications, but not removal of nodes etc. It can however be a starting point, and be extended to cover that as well.
EDIT
Here is a much shorter function, based on the same ideas but not using the mutable tree data structure.
Here is how you use it:
You can call
getExpression[]at any time to see the current value of expression or assign it to any variable, or you can useThis method yields much shorter code since the Mathematica native tree structure is reused as a skeleton for the tree, where all informative pieces (heads and atoms) were replaces by symbols. This is still a mutable tree as long as we have access to original symbols and not just their values, but we don't need to think about building blocks for the tree - we use expression structure for that. This is not to diminish the previous longer solution, conceptually I think it is more clear, and it is probably still better for more complicated tasks.