steps to phantasien

星空日記

Altair のコードなどを読む日記。

Vega Research Reading List

Stretch

Authorization Tools

2021/12/01 #1

  • とりあえずチェックアウトしたら 論文 が入っていたのでそれを眺める。
  • わかったこと: Altair のコードは Vega-Lite の JSON Schema から生成されている。そして Vega-Lite の JSON は Vega の JSON に変換され、例週的には D3.js でレンダリングされる・・・らしい。ほんとに？ Vega-Lite はいいとして D3.js はデフォルト(非対話モード)では使われない気がするけどな。Canvas に書いているような。Altair のコードは早めに切り上げて Vega-Lite のコードをよむのが正しげ。

ではコードを眺めましょう・・・

  • コード生成をしているのは altair/generate_schema_wrapper.py at master · altair-viz/altair. Vega と Vega-Lite と両方の schema を使っている。つまり Vega-Lite は独立した schema ではなくて、Vega の拡張というかんじなのかね。それは schema を読めば明らかに成ることだが・・・。
  • 生成されるのは このへんのファイル
  • 実質的に面白いのは utils/ とかで、ここには Vega-Lite の JSON をラップして JS でレンダリングする HTML を吐くコードがある。興味深いのは Colab 対応のコードが入っていること。(display.py)。しかしこれを enable する様子がない。Colab 側で対処されているのだろうか。Colab を検出するコードがあるなら見たかったんだけど。
  • 必要な NPM のライブラリは vega, vega-lib, vega-lite, vega-embed. これらはみな https://github.com/vega で開発されている。
  • というわけで Altair は Vega-Lite なりなんなりの JSON を作ってくれるのだよ！以上。Altair は JSON-Schema の generation だったのだねえ。JSON つくるところは見てないけど、まあ大したことないと思うのでいいです。

というわけで Vega および Vega-Lite を眺める。まずは Schema から。

巨大だなー・・・・。といったところで今日はここまで。

2021/12/02 #2

  • Vega 関係の論文を眺めるが・・・Research Publications | Vega
    • Vega そのものはないのだね。あってもバチはあたらないと思うが、新規性はないのかもしれない。Vega-Lite は昔読んだので割愛。
  • ではドキュメンテーションを見ましょうか。 手始めのチュートリアルは・・・めっちゃ対話的だな。SVG か。 これはほんとに D3 based なのだろうなあ。
  • この documentation によると vega-cli というツールでブラウザなしに PNG を作れるらしい。Altair も　Selenium 依存とかやめてこっち使えばいいのに・・・はさておき、canvas に書くらしい。D3 わかってないけど canvas に描けるんだっけ？これはコードを見るべきだな。
  • Repo の説明をよむと・・・なんかめちゃ reactive っぽい雰囲気だなー。しかも JSON の input の他に “data flow description” なる中間状態があり、それが最後は scenegraph になるらしい。
  • コードよりは Schema をよむほうが自分の役には立ちそうなので、ドキュメントをよむ。
  • それすらでかすぎるのでおとなしく チュートリアル からはじめます・・・。ようやく Altair で見覚えのある雰囲気になってきた。
  • そしてもういいかな、という気分になってきた・・・。自分は interactive visualization をそんなに信じてない、というのはいいすぎだけど、宣言的である限り大したことはできないと思ってるんだろうな。JS でバリっと作るくらいがんばるならいいけど、Python から JSON を生成していると限りなく静的だからねえ。
  • リサーチという点ではこういうインフラを作った上に色々リッチなものを積み上げ、interactive + declarative の地平を切り拓いていくことには意味はあるんだろうな。
  • このひとたちが Observable, Inc. になっていたのか。アカデミアでがんばってほしかった・・・。

さて・・・

  • 個人的には reactivity にコストを払ってデータサイズの制限をつけるくらいなら静的に振り切ってデータサイズにスケールするようにしてくれ、という気分がある。そういう意味で、一旦自分で Vega のレンダラを Skia あたりで書いてみるのは楽しそうではある。実用を目指すのは難しいにしても、娯楽として。
  • 一方で、自分は interactive visualization というものをきちんと appreciate できているのかという疑問もある。なのでこの UW IDL から出ている論文のうち関連のありそうなものを読んでみるのは良い気もしている。

つまり書くかよむかという話なわけだが・・・。まあ、読むかな。読むだけならすぐ終わるからね。

Reading List をつくってページトップに置くべし。

2021/12/03 #3

Reactive Vega: A Streaming Dataflow Architecture for Declarative Interactive Visualization

  • Vega, もともと (2015) は Reactive じゃなかったのか! それを FRP のブームにのってこんなことにしてしまったんだな・・・。
  • Stolte: Polaris: A system for query, analysis, and… - Google Scholar という Tableau のもとねた paper が grammar of graphics に並んで参照されている。GoG は古すぎる上に本一冊なので読む気にならないが、この論文は読んでも良いかもな。
  • 論文の常として Relate Work のセクションは素晴らしいな。この論文の位置づけを理解できる上に、streaming database とか FRP のリサーチまで参照されている。可視化については言うまでもない。
  • ただ Vega の挙動を理解するという意味では How Vega Works の方が簡潔＋具体的でよかったね。

2021/12/04 #4

というわけで Reactive Vega 了.

  • 感想としては、JSON なので損してるね。 “Grammar” という意味で簡潔さがなさすぎ。機械生成を前提としており、たとえば Altair はその簡潔さ部分を助けてくれている。が、JS にそれがないと Obsevable Inc. が目指すような JS 中心対話的可視化 notebook はつくれない気がするな。
  • あと UI イベントとデータを統合的に扱っていて、Reactive という観点でそれがいいのはわかるけど、結果としてデータ側の扱いが軽くなってる印象。リアルタイムにデータを流し込めれば dashboard とかで守備範囲が広がるはずだけど、そういうのの支援が特にない。Frozen なデータを対話的に drill-down する暗黙の前提を捨てきれていない。

というわけで Vega を Reactive にする判断は、個人的にはあまり convince されていないのだった。やりたいことはわかるんだけど。

  • つぎ。Prefuse: A Toolkit for Interactive Information Visualization. 2005 の古い論文なので軽く行くべし。
  • うげ。データソースが graph (Node+Edge) かいな。可視化もそれ系。マジどうでもいい・・・。というわけで次にいくべし。なお Java で実装されており時代を感じました。 この頃の可視化ってこういうやつだったかもね。ggplot2 (2007) は先進的だったな。
  • 一方でこう、データ構造をパイプラインにつっこんでレンダリングするところはどこか Reactive Vega というか現在の Vega の実装に通じるものがあるねえ。

つぎ Protovis: A Graphical Toolkit for Visualization 2009.

  • ここでついに GoG が言及されている！つまり (graph-based でなく) charting みたいな応用に視界を向けるに至った。ggplot2 は言及されないが Tableau が言及されており、これは Stanford つながりなのだろうな。ていうか Pat Hanrahan の研究室からスピンアウトしたのか。何らかのドラマの予感があるが、論文とは関係ないので先行くべし。とにかく Vega と Tableau は親戚なのだね。
  • よくみると脚注で “Grammar of Graphics の実装である ggplot2 はこんな風に書きます” とか書いてんな。ちゃんと本文から引用しろ！
  • なお実装は JS である。サンプルコードを見ると・・・。あれ、これまさに自分が Vega にほしいと思っていた JS (!=JSON) の DSL じゃん。
  • 可視化で Tufte の再現をやってるあたりがシアトル勢だねえ。
  • 比較対象が Processing だが、そりゃ plotting に特化すりゃプリミティブしかない Pocessing よりは簡素になんだろ。

了。

  • オブジェクトモデルに違いはあれど、ハイレベルには JS で ggplot2 的な GoG をしました、という話だった。
  • この時点では対話制はデータとは分離されていた。そんくらいでいいんじゃね、という気がするが reactive になってしまったんだね・・・。
  • データの扱いに型が全然登場せず、そのへんが JS だなと思う。そしてデータを可視化するのにその data source がここまで opaque だと見通しが悪くて厳しい。そこは DataFrame がベースにある R の世界に対する弱点だね。
  • これをがんばって refine していえばそれなりに良いものが出来た気がするが、なぜか Vega で JSON にしてしまったのだねえ。

つぎ Declarative Language Design for Interactive Visualization 2010

  • JS だった Protovis を Java に移植して、Protovis DSL の宣言的言語としての可搬性、表現力を demonstrate するぞ、という話らしい。
  • ただ DSL といっても internal DSL すなわち単なる API なので、テキストレベルで一致するわけではない。本当に単なる移植。
  • ただ宣言的な言語だから色々最適化できるんだよ！と色々最適化を頑張って見せている。この話 Reactive Vega でもあったな。
  • なぜ Java なのか？ Java の方が速いしアプリに embed したいかもしれないでしょ、と言っているが、10 年後の今から見ると完全にハズレな方向性だねえ。
  • Protovis の論文には全然登場しなかった実装の話が少し載っている。そしてだいたい Reactive Vega と同じだな（というか、そこで引用されていたのでこれを読んでいるのだが。） アニメーションの都合でシーングラフを作ってますよという話。そうかい。
  • それをシーングラフと呼ぶか AST と呼ぶかはともかく、DSL が作るデータ構造はレンダリング可能なデータ構造とは一致できないので、何らかの IR が必要なのは確かなのだろうね。それだと internal DSL にする旨味(実装のラクさ)が失われてしまう気もするけれど、まあ仕方ない。なおこの変換の過程でバイトコード生成とかして高速化してますよ、とある。
  • Java だから Android でも動かしたよ、というスクショがある。頑張ってるな。しかし性能評価では一切言及なし。そういう遅い環境でこそ高速化の意義があると思うが、推して知るべし。並列化とかはそれなりにがんばってる。「Java に持ってきたから速い」という論文なので、そのへんは Protovis より真面目。
  • discussion を軽く冷やかして読了。そして時間切れ。ここから Vega に向かうのは、まあわからなくもない。なんで Vega の論文はないんだろうね。

2021/12/07 #5

今日読むのは D3: Data-Driven Documents - 2011. D3 って本もあるくらいヒット作だけど完全にスルーしてたので良い機会であることよ。

  • D3 は基本的には SVG のために jQuery を作ってやったぞ、という話である。 GoG の仲間たちはそれぞれ語彙を再発明しているが、ウェブなら SVG という標準があるんだからこれに乗るのが筋だろ、という主張。
  • ただ素朴に jQuery 的 fluent API を実装するだけでなく、アニメーション、レイアウト、データを bind する仕組みなどもきちんと作り込んでおり、このへんの労によって使えるライブラリになっている。
  • ただサンプルコードを見ると・・・・なんというか、クリエイティビティを問われるね。SVG がむき出しすぎる。論文の中のサンプルもそうだけど、たとえば d3js のサイトからリンクされている Observable の gallery から Stacked bar chart を眺める。しかしなぜこれが stacked になるのかまったくわからない！適切なデフォルトとかも特に無いので、width に “-1” とか書いてマージンを調整している。厳しい。比較として Altair のサンプルを見よ。あるいは faceted scatter plot を比較せよ: D3, Altair.
  • 一方で、ミタメを完全にコントロールして novel な可視化をしたいガチ勢に良いツールだというのも理解できる。たとえばこの stacked bar から grouped bar への遷移アニメーション, なんの意味があるのかまったくわからないがとにかくかっこいい。こういうのは Altair / Vega では単純に不可能。
  • D3 は宣言的な GoG に対するアンチテーゼとして API を手続き的な側に寄せた。一方で SVG や DOM という Web のプリミティブを活かすことで、ある程度宣言的な要素を残した。その結果として可視化ガチ勢の必須ツールとなった。偉業。
  • ただ自分は可視化ガチ勢ではないのでお手上げ。個人的には D3 の上に同じ方向性で charting のためのライブラリを積み上げてくれればよかったのにと思うが、そういう事は起こらなかったのだねえ。Michael Bostock が興味なかたのだろうな。残念。かっこいい可視化をしたい人生のターンが来たら真面目に勉強します。

つぎ Declarative Interaction Design for Data Visualization, 2014. ちょっと前に読んだ論文とほぼ名前が一緒で紛らわしい…

  • とおもったが Reactive Vega の話だった。
  • Interactivity ってどうしても手続き的というかコードを書きたい場面があるのに、それを JSON で表現しなくてはいけないところに罰ゲーム感がある。Vega の Internal DSL を捨て JSON を選んだ結果プログラミング言語の支援が失われた痛みが強く出てる。
  • さっと眺めるくらいで終了。お疲れ様ですね。

明日は Vega-Lite の論文を読み直すわけだが、こうしてみると Protovis から D3 と進んだものの D3 が takeover 仕切らず Vega で宣言的な方向性を強める方に振り戻してしまったのは、なんかちょっと残念だよな。おかげで Altair みたいなものが可能になったので文句は言えないんだけど、JS の可視化世界征服のためには Altair の JS 版が必要なんじゃないの？ JSON とか書かせないでくれよ。なんで無いのだろうね、というかほんとに無いのかな？

… と調べると vega-lite-api というのがあった。(サンプルコード). オフィシャルサイトのドキュメンテーションで全然推されてないのはなんなのだろうね。

まあいいです。今日はここまで。

2021/12/08 #6

今日は Vega-Lite 2017 を再読。(前回の記録)

  • Vega-Lite のモデルをそこそこ丁寧に解説しており、良い導入になっている。
  • Vega ではなく Vega-Lite が GoG/ggplot2 のライバルだと理解。Vega は思ったよりシンプルで、たとえば様々なデフォルトを解決してくれたりしない。言われたとおりに書くだけ。一方の Vega-Lite はそういう類推および簡単な集約などをやってくれる。おかげで記述がシンプルになる。
  • 論文としての novelity がどこにあるかというと interactivity を GoG に持ち込んだこと。これは他には誰もやっていない。が、個人的には興味ないなあ・・・。D3 とかをやってから戻ってくると有り難みを感じるのかも知れないが、普段の plotting 作業で対話制野必要性を感じることないからね。

Vega-Lite でようやく ggplot2 に（だいたい）追いつき、ある面では追い越すことが出来た。が、やはり JSON が足枷に感じるよなあ。簡潔といいつつ JSON というものの本質的な記述力の低さが足を引っ張っている。これは vega-lite-api や Altair で解決されているわけだが。

対話性にしても、exploratory visualization に使えると言っているが EDA には弱いのだよね。JS というか JSON だとでかいデータを処理できないから。自分が EDA しようとおもったらまず SQL を書く部分で色々パラメタを変えて試行錯誤するから、それが「対話・探索」に相当する。Vega-Lite はそういうデータソースの tweak には向いてない。SQL なり Pandas なりの filtering/reshaping 能力に比べると Vega-Lite の transform とかしょぼくて使い物にならない。覚える気も起きない。

別の見方をすると、Vega-Lite のいう exploation は可視化つき資料を書く人が可視化つき資料を読む人のために用意するものである。たとえば NYT の記者がインタラクティブな可視化つき記事に埋め込む可視化とかには使える。これまでは D3 でガッツリ書かなければいけなかったよそ行きの対話的可視化を、分野を限ればサクっと作れるようになる。

そこに価値があるのはわかるが、自分がほしいものではない。自分は自分自身のために探索をしたいわけだから。こうして Vega-Lite の可視化の位置づけと自分がそれに不満な理由を理解できたのはよかった。

Vega に対して Vega-Lite が追加した対話性以外の部分、つまり既存の GoG に対する feature parity は、novelity はないかもしれないが実用という意味では重要で、いい仕事をした。おかげで Altair ができるわけだからね。

さてこれで Altair に至る道筋が理解できた。読み残しているのは UW の人たちの最近の論文と、Vega への影響の強い昔の論文たち。どっちから読もうか。まあ先に UW シリーズを終わらせておくかな。

というわけで Communicating with Interactive Articles, 2020

  • これは(少し前に休刊になてしまった) Distill です。Distill の休刊には G Research の凋落を感じてしまう。まあそれはいい。
  • サーベイ記事なのでちょっと長いね。
  • 了。感想はあとで。

2021/12/09 #7

Communicating with Interactive Articles:

  • まずオンラインの様々なインタラクティブ可視化記事を参照しながら、インタラクティブ記事の利点を説明していく。このパートは単純にリンク集として素晴らしい。あとで読む。
  • 次にインタラクティブ記事を作る上での壁を議論する。まずインセンティブの壁（たとえば研究者には時間をインタラクティブ論文を書く動機がない、それより静的な論文を量産する方が良いから、など。）これはまあ、どうでもいい。
  • そしてもう一つの壁、すなわち技術的な困難を説く。新聞社の可視化記事とかチームで作る前提、Distill の記事も Git clone して HTML を編集するコラボレーションスタイル、そんなのプログラミングリテラシーがないとムリじゃんと。
  • 著者らは解決策の一つとして Markdown の可視化拡張 + static site generator の Idyll というのを作っている。要するに Vega chart を埋め込めるわけだが・・・これは Jupyter と比べてそんなに嬉しいのか？研究としてはいいが、実用したいとは特に思えない。
  • ただし著者らはこれを dogfood して Parametric Press という online mag を issue 2 まで出しており、そこは評価できる。
  • これだけでなく、いくつかのインタラクティブ可視化がんばろうなムーブメントを紹介し、同時に NYT の中の人が “インタラクティブなの作ってもみんな触ってくれないからやめるわ” と 言ったスライド などを参照しつつ、可能性はあるからがんばってこうな、と締めくくる。

UW IDL のみならず周辺の可視化研究者の立場がよくわかる論文だった。やはり自分でデータを突きながら open-ended の探索をするよりは、何らかの insights がある前提でそれを communicate する手段としての対話的可視化なのだよな。

そしてプログラマというのは、対話的可視化ができるコンテンツおよびツールを生み出す上でかなり良い立場にいる。なぜならコードが書けるから。もちろん書くべきコンテンツがあるとは限らないが、もしデータに基づいて何かを発言するなら対話的可視化をつけてなんか言う方がいいんじゃないか、と思うに至った。なぜならプログラマにはそれが可能だから、面倒ではあるかもしれないが・・・。

ただ面倒くさいのは事実。著者らも “reating a successful interactive article is closer to building a website than writing a blog post” と書いている。そういう意味で単一のデータ/データセットに対する対話的コンテンツを作るのはプログラマであってもなかなか割にあいにくい。

一方、データを扱うツールみたいのを作るなら、もうちょっと対話性をがんばってもいいんじゃないか。自分はいま仕事のサイドで Perfetto Trace をクエリして興味のある指標をダンプするコマンドラインツールを作っており、そのツールに静的なチャートを埋め込めないかというのが Altair のコードを読みはじめたきっかけだった。が、コマンドラインツールではなく JS のウェブアプリにして、trace のファイルをアップロードすると色々チャートを出してつつける、という方が人々も触る気になるんじゃないか？（今はツールが指標を書いた markdown をバグトラッカーにアップロードする作りになっている。)

隣のチームではデータを可視化する Python のライブラリを書いてそれを呼び出す Colab noetbook のテンプレを配布している。それでも悪くはないし敷居は低いが、ウェブベースのツールにしたほうがより敷居は下がるよね。

ここには手間と見返りのトレードオフがあるが、すくなくとも単一の対話的可視化記事を作るのに比べるとツールをがんばる方がだいぶ割が合うように思える。自分もともとは他人のための可視化には興味がなかったが、なにか頑張る余地があるのかもしれないと考えを改めた。EDA には大げさ過ぎると思っていた D3 も、何ができるか触っておくとツール業の足しになるかもしれない。

など、それなりに対話的可視化の価値を見直すきっかけとなった。

つぎ Critical Reflections on Visualization Authoring Systems, 2020

  • なんらかの振り返り論文。
  • 筆頭著者 は MIT の人らしい。このひとの研究室をみると・・・・似たような研究をしているね: MIT Visualization Group
  • 可視化を GUI で作るツールを過去に色々作ってきたから振り返るよ、という話だった。興味ねー。著者は “A shared assumption underlying our systems is an author’s desire to visualize data without programming while still exhibiting a level of comfort with computational thinking” と書いており、一方自分は pogramming する方にバイアスがあって GUI でポチポチ dashboard を作るのにはウンザリしているので、やむなし。
  • そしてダッシュボードという観点で見ると、ツールは SVG や Vega をエクスポートできるらしいが、そんなもん貰ってもなあという残念感。最終的な成果がブラウザで消化され、かつデータソースはダイナミックに降ってくるわけだから、そのツールも dashboard に住んでるのが自然じゃね？(Web-based ではあるらしい。)
  • ただ Vega (JSON) をエクスポートして、データの部分はテンプレにすれば他のツールにも持っていけるよと言っており、そういう用途が念頭にあったからこそ Vega は JSON なのだとわかる。
  • なにかと Power BI が参照されていてなんでやねんと思ったら、著者の一人は MSR で可視化ツールの研究をしているらしい。へえ。

この論文は話題になっている可視化ツール (Lyra, Data Illustator, Charticulator) がわかってないと意味不明だな。終了。あとで一つくらい読んでやるとしよう・・・。

というわけで Lyra 読む？とおもったけど著者の一人は最近 Lyra2 というのを出しているので、これを読んでみるかな。MSR のも気になるけどね。

Lyra 2: Designing Interactive Visualizations by Demonstration | MIT Visualization Group, 2020

  • Lyra (1) に interactivity を足したよ、Vega-lite を出力できるよ、というものらしい。興味わかん・・・。
  • Lyra は GitHub にあり(vega/lyra), Lyra 1 は 実際にさわれるものがオンラインにある. Lyra 2 はまだリリースされていないらしい。なんやねん・・・。
  • で Lyra 1 をさわってみると・・・なんちゅうか、会社の dashboarding tool の方が普通に良く出来てるな。Lyra 2 の論文を見るとその手の dashboarding tool (Tableau とか) はテンプレートベースで表現力がないので、Vega / Vega-Lite のようにもっと表現力の高い可視化を提供すると言っている。がしかし、そのために使い勝手の敷居が上がりすぎじゃね？
  • Textural representation より敷居が低いとかいうけど、コードはコピペすればだいたい動くからサンプルのコピペを起点にいじっていけるのに対し、Lyra は一からデータを作っていかないといけない。もちろん理論上テンプレートは提供できるわけだが、SO とかからコピペできる textural representation の versatality には全く及ばないのではないか。
  • 論文中では使い勝手の工夫とかユーザビリティの評価とかしてるけど、まあどうでもいいかな。わたくしはテンプレベースの GUI か textural representation があればそれでいいです。

がっかりしつつ、いちおう MSR のやつも読んでおく:

Charticulator: Interactive Construction of Bespoke Chart Layouts - Microsoft Research, 2018

  • が Abstract よんでパラパラ眺めてだけでもう興味の無さが限界に達してしまった・・・。
  • オンラインで試せる: https://charticulator.com/ が、やはりわけわかんない。
  • Power BI とインテグレートしてるのは偉いなと思いました。

以上。Tableau 路線 Authoring tools の必要性には説得されなかった。今日はここまで。 明日はその Tableau の論文でも読むべし。