Day: April 4, 2022

執筆活動 – m.g.i

Message Passing 書き終わり。そのほかお手紙に返事など。

Windows には最近は scoop という便利インストーラがあると教わり入れてみる。(参考: MacOS ユーザが WSL では無い Windows のコンソール環境を整える – A Day in the Life)

お、いいじゃんと勢い余って duckdb を Windows native でビルドしようとしてみるが、なんかいろいろ足りず挫折。また今度・・・。そして Windows ネイティブ開発しようとするとダウンロードサイズがでかい。つぎ laptop 買うときはでかめの SSD が欲しいかもしれないなあ。

参考リンク

誤読活動 – The Grammar of Graphics

The Grammar of Graphics | SpringerLink

というわけで一通り読んだが・・・わけがわからん。

ハイレベルな主張はそれなりに理解できる。つまり、データの可視化というのは以下のようなステップからできていて、それぞれのステージの仕様を指定の上データをつっこめばグラフができるんだよ、というはなし。 *

  • まず入力は Data. これがなんなのかははっきりしないが、最初のステップ “Variable” ではこのデータを “Varset” というやや奇妙なモデルに変換する。これは雑に Pandas の indexed Series だと思えば良い。つまり、基本的には配列だが、ここの要素に index (ID) がついている。この index のおかげで他の Varset と Join できる。
  • 次のステップは “Algebra” で、ここで実際に join したりする。つまりこの Algebra は関係代数みたいなものである。なんか微妙に関係代数とは違うっぽいが、なぜなにが違うのかもその動機もはっきりしない。実際 Polaris では「我々はオリジナルを無視して関係代数に寄せます」といっている。
  • 次のステップは “Scale”. たとえば線形だったのを log scale に map したりする。
  • 次のステップは “Statistics”. ここで何らかの aggregation を行う。しかしどうやって group by 相当のことができるのかはナゾ。
  • 次は ”Geometry”. Point, Line, Area, Bar, Histobar, Tile, Contour とかを選びます。ここまでパインプラインの上を流れてきたのは Varset だったけど、この出力は Graph です。何が違うのかはナゾ。
  • 次のステップは “Coordinates” です。座標系を選びます。表示したいデータの次数が二次以上なら projection とかもします。
  • 最後が Aesthetics です。これはデータをどの見た目にマップするかを選びます。 x, y, color … このステップを通るとデータは ”Graph” から “Graphics” になります。これで無事描画できます。よかったですね。

よくねえええー。

この論文から Altair 的なものの面影を見ることは、頑張ればできなくもないが、これを読んでなにか可視化システムを実装できる気が全くしない。あまりに細部や具体性がかけている。Polaris paper を読んだ瞬間に「これ我々が使ってるダッシュボードの祖先じゃん！」と全てを理解してショックを受けたのとはだいぶ違う。

この論文が（回顧論文であることを差し引いても）2012 に出ていることを考えると、ひどくない？なんか引用されてる話題も 2002-2004 あたりで止まってるしさあ。本を読むともう少し理解が深まる可能性はゼロではないが。個人的には「この著者はイマイチ」ということで打ち止めにしておきたい。重要な（かもしれない）アイデアを、ひどく不可解な形で公開してしまった Research Debt だと言えよう。$30 は無駄だった気もするが, GOG (as its original form) は overrated と結論できたのは良かった。Let’s move on.

こんな意味不明なものから GUI 側では Polaris/Tableau を生み出した Pat Hanrahan, API 側では ggplot2 を生み出した Hadley Wickham はマジ神。

そういうムカついた気分はさておき振り返ると、なぜ BQ でひっこぬいたデータを Altair で可視化する作業にもどかしさがるのか、またなぜ内製の可視化ツールはイマイチに感じるのか、理解が進んだ。

まず BQ+Altair のイマイチさは、Altair の ”Statistics” 機能の足りなさが一つの理由だと言える。GoG の世界において statistics すなわち aggregation はパイプラインの一要素である。SQL でデータを扱う我々は SQL で aggregate したいが、Altair の可視化は SQL から分断されたオンメモリの世界で起こる。オンメモリどころかデータを JSON で直列化する必要から 5000 件みたいなデータサイズの制限がある。aggregate するのは大量のデータから特徴を読み取りたいからなのに、その「大量」が 5000 件で cap されちゃうと厳しい。あと Altair というか Vega 側が色々な aggregation を実装しなおさないといけないのもムダ感がある。

よりハイレベルには, visualization と statistics は切り離せないというのが GoG の洞察なのに、Altair/Vega-Lite はそれを切り離してしまっている。これは R の世界で全てが閉じている ggplot2 にはなさそうな問題に見える。しらんけど。

個人的にはオンメモリで頑張るより Polaris みたいに可視化仕様から SQL を生成して必要なデータ整形を全部済ませるアプローチが Python の世界に来てほしい。Vega-Lite のレイヤを JS じゃなくて Python 側に持ってくるのが一つの方向性だろうけど、そういうことは起こらないだろうなあ・・・。

つぎに社内 dashboarding tool のイマイチさだが、これは可視化仕様の指定に GoG 的な composability が足りてないからだろうね。内製ツールの話をここに書いても仕方ないので細部は省略するけど、もうちょっと頑張ってほしかった。

以上。