Multiple Outputs #41
jmorris335
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I think we can have multiple outputs. Our functions map from a set to a set, that's always true. But we're completely fine saying the domain of each function is the Cartesian product of a set of nodes. Why aren't we fine with saying the codomain of the function is the same?
For the source set, we create the domain set by taking the product of every source node. What if the mapping was from this domain to another set. If the codomain is a single variable, great, that's what we already have. Otherwise, if the mapping is to multiple variables, then we take the projection of the output and assign it to each node.
I don't see how this would be a problem. It makes divergent paths, but so would running a projection node from each member of a vector. There's no difference, except it avoids the redundant step of having to compile a vector and then pick it apart again.
For instance, say we have a hyperedge$e$ defined as $A, B \xrightarrow{e} C, D$ . Right now, the only way to do this is to decompose $e$ into the following:
where$e_2$ and $e_3$ are projection functions, and $\overline{CD}$ is a set whose values are vectors of the kind $\lbrace C, D \rbrace$ . This is three functions for one operation! Even worse, it means when tracking dependencies that we've actually duplicated $C$ and $D$ , because we're treating $\overline{CD}$ as a separate variable. That's not very desirable.
Instead, the work of projection should be handled autonomously by the solver, in the same way that$A \times B$ is automatically configured. Off the top of my head, I don't see any reason why this would break pathfinding, though implementing it might mean redefining some of the pretty print functionalities.
Beta Was this translation helpful? Give feedback.
All reactions