4 ms·

This is interesting. How do you visually identify a function with multiple inputs and outputs? I tend to imagine it as a bi-graph - with boxes for values and f

This is interesting. How do you visually identify a function with multiple inputs and outputs? I tend to imagine it as a bi-graph - with boxes for values and for functions, and arrows in between. The stack idea is interesting and can work here too. I could get behind saying "all functions have exactly one input value and one output value" but you really need to be able to construct and deconstruct structs/records/tuples to be able to e.g. pass two values to one function.

__MatrixMan__ 2y ago
Ah, yeah, you caught me. It's not so simple as a transform from nodes to edges. What I actually have in mind is a bit stranger, but the node/edge swap was my stepping stone towards it, which is why I mentioned it. The structs/records/tuples approach would work (I think this would correspond with "currying"), but I have this weird idea that certain types of reasoning have a "shape" and that we might be able to more heavily lean on analagous reasoning if we could easily show that shape in correspondence with explanations of our reasoning. I worry that currying everything would force us further away from the "natural" shape (if there even is such a thing). I've been working on something called plibs (simPlical mad LIBS, since really we're showing a https://en.m.wikipedia.org/wiki/Simplicial_complex https://en.m.wikipedia.org/wiki/Simplicial_complex here). The functions are represented as tuples of the same arity, and described via sentences with blanks in them (e.g. when you run ____ code in ____ environment you get ____ from stdout). One with three blanks would then appear like a triangle and then I'd fill it in with a gradient indicating which sides are inputs and which are outputs. Functions sharing a mad lib would appear as a regular polygon in the same color (one edge for each blank). Or maybe they're sort of starfish shaped so that each leg can reach out an touch whatever the data representation ends up being. One could imagine algorithms that generate patchwork quilts or 3D structures (like how protein folding is represented) out of such things. These could be computed only in one direction (from inputs towards outputs) but they could be traversed in any direction if one wanted to explore the relationships. I'm hoping it will be a nice way of citing your computational sources. You would attach them to any computational result (alongside a scientific paper, perhaps) as a way if saying "here's how I came up with this, rerun it to verify my result". Aside from the computational pathway that yielded the result that's being scrutinized, you could explore adjacent plibs to understand why certain inputs were chosen or to gain other contextual hints. Now that I'm describing it it sounds a bit like that awful zooming-through-towers-of-data visualization in "Hackers" the movie. So the "edge" that I was using as a progress bar in my previous description is really a series of paths through a space made of these things. The details of the functions being called (and of the datasets being generated) are attached to the polygonal regions that the paths connect. The paths may merge or branch. It could get unwieldy, so the user would have to be explicit about which plibs to show and which to highlight as a chain of computation. As for how the represent the intermediate data and their types, I keep changing my mind. Some days I like the stacks of cards thing, some days not. Hopefully something will sick soon, then I'll try to build it.
- andyferris 2y ago
  This is late, but I just saw this. Wow that’s a pretty wild idea. Quite interesting. I’m not sure what to consider “natural”. I know category theory (I’m a physicist by training, not CS, so I’m not talking Haskell or whatnot) tells us that these 2D drawings of computation graphs have a well-defined meaning (eg you can deform the lines continuously and it doesn’t change the result, etc). In particular, we have these monoidal categories where we can e.g. draw two lines in parallel to represent two pieces of data flowing. The thing is the “monoid” can either by the product (two values in a struct, say) or a sum (two possible values in a variant) and you get the same “rules” for how to draw it. Back when I was drawing tensor network diagrams it would really tricky to include both monoids on the one diagram. You could kinda do it in 3D but that’s not natural or easy. What people do in practice (in flowcharts, etc) is we tend to have these AND and OR junctions (and their inverses) where a human can kinda infer what’s going on (e.g. does this split and join refer to two parallel computations or branching logic?). I think both monoids are critical to expressing computation and I still don’t know what the “natural” yet “rigorous” way to draw these things is.

__MatrixMan__ 2y ago

Ah, yeah, you caught me. It's not so simple as a transform from nodes to edges. What I actually have in mind is a bit stranger, but the node/edge swap was my stepping stone towards it, which is why I mentioned it. The structs/records/tuples approach would work (I think this would correspond with "currying"), but I have this weird idea that certain types of reasoning have a "shape" and that we might be able to more heavily lean on analagous reasoning if we could easily show that shape in correspondence with explanations of our reasoning. I worry that currying everything would force us further away from the "natural" shape (if there even is such a thing). I've been working on something called plibs (simPlical mad LIBS, since really we're showing a https://en.m.wikipedia.org/wiki/Simplicial_complex https://en.m.wikipedia.org/wiki/Simplicial_complex here). The functions are represented as tuples of the same arity, and described via sentences with blanks in them (e.g. when you run ____ code in ____ environment you get ____ from stdout). One with three blanks would then appear like a triangle and then I'd fill it in with a gradient indicating which sides are inputs and which are outputs. Functions sharing a mad lib would appear as a regular polygon in the same color (one edge for each blank). Or maybe they're sort of starfish shaped so that each leg can reach out an touch whatever the data representation ends up being. One could imagine algorithms that generate patchwork quilts or 3D structures (like how protein folding is represented) out of such things. These could be computed only in one direction (from inputs towards outputs) but they could be traversed in any direction if one wanted to explore the relationships. I'm hoping it will be a nice way of citing your computational sources. You would attach them to any computational result (alongside a scientific paper, perhaps) as a way if saying "here's how I came up with this, rerun it to verify my result". Aside from the computational pathway that yielded the result that's being scrutinized, you could explore adjacent plibs to understand why certain inputs were chosen or to gain other contextual hints. Now that I'm describing it it sounds a bit like that awful zooming-through-towers-of-data visualization in "Hackers" the movie. So the "edge" that I was using as a progress bar in my previous description is really a series of paths through a space made of these things. The details of the functions being called (and of the datasets being generated) are attached to the polygonal regions that the paths connect. The paths may merge or branch. It could get unwieldy, so the user would have to be explicit about which plibs to show and which to highlight as a chain of computation. As for how the represent the intermediate data and their types, I keep changing my mind. Some days I like the stacks of cards thing, some days not. Hopefully something will sick soon, then I'll try to build it.

andyferris 2y ago
This is late, but I just saw this. Wow that’s a pretty wild idea. Quite interesting. I’m not sure what to consider “natural”. I know category theory (I’m a physicist by training, not CS, so I’m not talking Haskell or whatnot) tells us that these 2D drawings of computation graphs have a well-defined meaning (eg you can deform the lines continuously and it doesn’t change the result, etc). In particular, we have these monoidal categories where we can e.g. draw two lines in parallel to represent two pieces of data flowing. The thing is the “monoid” can either by the product (two values in a struct, say) or a sum (two possible values in a variant) and you get the same “rules” for how to draw it. Back when I was drawing tensor network diagrams it would really tricky to include both monoids on the one diagram. You could kinda do it in 3D but that’s not natural or easy. What people do in practice (in flowcharts, etc) is we tend to have these AND and OR junctions (and their inverses) where a human can kinda infer what’s going on (e.g. does this split and join refer to two parallel computations or branching logic?). I think both monoids are critical to expressing computation and I still don’t know what the “natural” yet “rigorous” way to draw these things is.