You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if someone resolves a formula above a bunch of open branches, they will have to fill in the new formulas separately on every branch.
We've discussed two ways of making this easier on the user:
Allow the user to select a subtree and duplicate it below another branch. To do this relatively simply, we'd have to only allow this to be done from the same row. We'd have to decide what should happen if the target node has a different-shaped subtree than the source root.
share the formula value between different branches on the same row. This requires some adjustment to how we represent the state of the tree.
Having thought about this a bit, I suspect approach 1 would be much trickier to implement, and require that we answer some additional questions about how it would behave. Since the pedagogical benefit of 1 over 2 is only hypothetical, I would prefer to implement approach 2 for now.
The text was updated successfully, but these errors were encountered:
McTano
changed the title
Allow copying of subtrees to make adding many branches more convenient.
Avoid manually entering formulas at each node when they are created on the same row
Jul 21, 2020
Right now, if someone resolves a formula above a bunch of open branches, they will have to fill in the new formulas separately on every branch.
We've discussed two ways of making this easier on the user:
Allow the user to select a subtree and duplicate it below another branch. To do this relatively simply, we'd have to only allow this to be done from the same row. We'd have to decide what should happen if the target node has a different-shaped subtree than the source root.
share the formula value between different branches on the same row. This requires some adjustment to how we represent the state of the tree.
Having thought about this a bit, I suspect approach 1 would be much trickier to implement, and require that we answer some additional questions about how it would behave. Since the pedagogical benefit of 1 over 2 is only hypothetical, I would prefer to implement approach 2 for now.
The text was updated successfully, but these errors were encountered: