视频如下，附有文件。 该项目大约分三个阶段完成：数据收集、耗时的预处理步骤和视频帧创建步骤。
数据是由 wikipediaTextParser.jsl 收集的，它下载了大量维基百科网页（分几批完成，历时几天）。 维基百科主页上有一个随机按钮，其中有一个返回随机文章的链接。 JMP 可以循环打开该链接，并将 HTML 写入表中。 （如果你这样做，你真的应该考虑在他们下次要求时捐赠。）下载循环还进行了一些处理，以删除一堆 HTML 并尝试识别文档中有趣的部分；您仍然会在视频中看到一些本应被过滤的单词。 此步骤还搜索特定格式的日期，以尝试为每篇文章分配日期；最古老的日期似乎是最好的，因为大多数文章都经常被触及。 完成后，按日期排序。
Generator2.jsl是预处理步骤；它使用 JMP 的文本浏览器平台来查看文档的子集。 我从所有文档开始，列出了已删除的停用词。 每个子集大约有 1500 个文档，并且与之前的子集有很多重叠。 每个子集中都会保存一个术语表，并将其复制到一个更大的表中。 较大的表有 300 行 x 3600 列。 我保留了 300 个最流行的术语，我需要 1800 帧才能制作 60 秒的 30 帧/秒视频。 每对列都是一个术语和一个频率。 是的，如果我重来一遍，我可能会将其旋转 90 度，得到 600 列 x 1800 行。 这运行了一夜。
ProcessMC4.jsl（最后一步）主要是 JSL 来构建数据以提供给 Graph Builder。 我使用“用于标记”将术语转换为图中的单词，并让图形生成器计算出有多大。 有相当多的 JSL 运行力导向帮助单词找到一个闲逛的好地方的算法。 在视频的最后，您可以看到数据停止流动后残留的抖动，但强制引导的代码仍在运行。 尽管如此，这仍然每秒生成几帧。 （我做了很多调整来找到一些效果很好的力导向参数。 令人惊讶的事情之一是，当单词查看其最近的邻居时，发现“少即是多”：1 或 2 个单词在单词周围得到了很好的间隙，但 5 个或更多单词则表现不佳。 也许我在求和力矢量时弄乱了距离计算。）
视频（想要最大化，有很多小字）
所有视频
