影片如下，附有文件。 此專案大約分三個階段完成：資料收集、耗時的預處理步驟和視訊幀創建步驟。
資料是由 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 個或更多單字則表現不佳。 也許我在求和力向量時弄亂了距離計算。）
影片（想要最大化，有很多小字）
所有影片
