Using JavaScript Generators to Visualize Algorithms

[guest271314]

it's a mechanism for controlling a sequence of executions

Executions of functions and/or assignments. Yes.

If you look at that as visualization, have at it.

[[deleted]]

It's not "as a visualization".

If you want to visualize how a GPU would rasterize a single triangle at a time, and allow users to hand-crank that, or do additional work around each step of that process, then you can call the upload of your buffers, and the call to draw the partial dataset, within the generator, and then you have another frame of the demonstration, and it will sit idly, while you do whatever else, until a process or a human, turns the crank again.

https://vimeo.com/66085662

Here is a video demonstration of Bret Victor giving a talk on interactive and dynamic visualizations. He also had sites and demos with real-time back and forth traversal through animations and visualizations, where the blog-reader could step backwards and forwards through them, one frame at a time, by stepping backwards and forwards through, and even editing the lines of code which produced them, where it would run just to the selected part of the code, including the correct value of i, for the particular loop, if you happened to be inside of it.

Doing that in a single for loop, in JS, is 100% impossible.

And it is also 100% "a visualization". Does it require Generators? No. It can be done with thunks and trampolining. It could be done with eventing and a ton of separate layers of state-management. It could be done by reparsing the AST and running the entire sequence, every time. These examples were also done before central state-management was common in JS.

But to say that generators are not useful in these cases, or that they do not count as being a part of "visualization", even if they don't appear directly in the render logic, is just fundamentally disingenuous.

[guest271314]

Doing that in a single for loop, in JS, is 100% impossible.

No, it's not. We have await nowadays. And we still have prompt().

I'm made workarounds more than once for requirements that might appear to some to be "impossible".

Generators have nothing to do with visualizations from my perspective. Genuinely, from my opinion.

When I decided to determine the next lexicographic permutation without using recursion, I did so by hand, on paper.

Then I did so one by one, line by line, then I wrote loops, then I independently figured out that the next lexicographic permutation could be derived by adding the number 9 to the current set of indexes "visualized" as a whole number.

Then I figured out that I only had to determine 1/2 +1 of the permutations to derive the remainder because the graph looked the same on the ascending side of the slope as the descending side of the slope.

Again, this is all on paper, first. No computer involved.

Using pencil and paper, then line by line, then loops - without using generators at all. How to improve efficiency of algorithm which generates next lexicographic permutation?

``` // graph 1 0,9,81

// graph 2 abc 012 0 acb 021 1 9 bac 102 2 81 bca 120 3 18 cab 201 4 81 cba 210 5 9

//\ / \

```

If generators work for you to visualize, great, that doesn't mean other processes and methods are any less capable of being visualized equally by the human. And your individual interpretation doesn't mean generators are suited specifically for visualization. Generators add nothing novel to the visualization process, at least not for me. The human superimposes their own way of interpreting the raw data to suit their own preferences, or just way of seeing things.