persistent diagram

https://github.com/scikit-tda/scikit-tda
Scikit-TDA is a home for Topological Data Analysis Python libraries intended for non-topologists.
はい。私のような non-topologist でも persistent diagram を簡単に作ることができました。
Mapper よりも Topology って感じです。

https://github.com/GUDHI/
The GUDHI library is a generic open source C++ library, with a Python interface, for Topological Data Analysis (TDA).
Tutorial がたくさん。こちらは触っていませんが、バーコードもかけるようですね。機能豊富です。

persistent diagram ではデータセットで対比するので、個々のデータをあてはめて予測、という使い方ができません。高次元のデータや図の比較、時系列データなどが対象になるのでしょうか。 

時系列データへの適用例です。
https://arxiv.org/abs/1803.00208 

これなら機械学習と同じ枠組みが使えます。動画での異常検知にもきっちりハマりますね。既存の手法と比較し良い方を選択するか、両方使うかでしょう。今後の動向に注目です。

 

KeplerMapper 2.0,0

Kepler Mapper を試行。
https://github.com/scikit-tda/kepler-mapper

example を動かしたのですが、そのままでは Version 違いで動きませんでした。最新版の API reference を参照し、修正したら動きました。ついでに mapper.visualize で html に。

図はできました。が、思っていたほど topology が主体ではないですね。コードを見る限り、UMAP で次元を圧縮してから DBSCAN でクラスターを作成してます。これだと機械学習分野の前処理と変わらないのですが、その後、クラスター間の線をつないで図ができています。つなぐぐか、つながないかの判断が topology なんでしょうね。

感覚的には分かったので、説明を検索。
Mapper の説明。3人目の方が話されています。
https://aip.riken.jp/video/aip-open-seminar-2/?lang=ja

Mapper
・ Extract the "shape" of complicated data.
・ Local clustering + global information
・ Generalization/"discretization" of Reeb graph.
・ Tool for exploratory (topological) data analysis.

0. prepare the data
1. Choose filter function
2. Partition (with overlap) using filter and cover
3. Perform Clustering in each partiton
4. Create Mapper graph
 Each cluster is represented by a vertex.
 Draw an edge if there's a non-empty interaction between two clusters.

上の例では UMAP が filter function に該当するのでしょう。動画ではＰＣＡが紹介されています。

Reeb graph って何だろう、と探してみたら、良い動画がありました。比較により、Mapper の特徴がよくわかります。
https://www.youtube.com/watch?v=_tiv0qYcM3U

この動画の冒頭で紹介されている文献は Kepler-mapper でも参照されています。よくわからない部分が多いのですが、動画の解説部分は理解できましたので必要に迫られるまで寝かしておきましょう。

***********************************************************
202010827追記
実際のデータ（10,000,000＊3）を入れたら、MemoryError。クラスタリングに sklearn を使っているからでしょう。実務での利用は難しいかな。

概念モデルの不確実性

「地下水モデル―実践的シミュレーションの基礎― 第2版」より

2.4 概念モデルの不確実性
・全ての概念モデルは定性的で不確かなものである。（すべての複雑性を表現できない）

・その不確実性に対して２つのアプローチがある
１．新しい情報を入手した時に、概念モデルを更新・訂正する。（進化する仮説）
２．概念モデルの代替え案を作成する。（複数作業仮説）

・好ましいモデルはモデリング過程で更新・改定されたもの。
・好ましいモデルが十分にキャリブレーションされ、不確実性解析で良い結果を与えると判断されて最終的に使用する概念モデルとして生き残る。

・実際には、プロジェクトの予算とモデリングの目的によって、アプローチにどれだけの労力を割けるかが決まる。

エンジニア

複数のエンジニアと話をする機会がありました。

感動しますね。プロは想像以上に理解が早い。私が１週間かけて理解した数式やコードを、２、３日で完全に読破されています。問題点やそのレベルの評価も一致。このような人材が揃っている会社って、素晴らしいの一言です。
話していると知らなかった知見があふれてくるようで、それも面白い。一緒に仕事をしてみたいなと思わせる方々でした。

私も、お客様にそのように思っていただいたことはあるのでしょうか？自信がないですね。
仕事内容の変化に伴い話す機会は減りましたが、できることを続けておきましょう。

V&V

お客様より V&V を記載するようお願いされていた先輩。
Verification と Validation を逆に回答されていました。

V&V は数値計算の分野で聞きます。最近読んだ図書では既に古くなった考え方ともとらえられますが、どうなんでしょう。

土木分野では、設計時に決められた手法で決められたものを作ることを繰り返すためか、暗黙的に保有する設計ツールを受け入れているように感じます。そのためか、稀に計算ソフトの Verification 不足に起因した不具合が発生していますし、ある程度は「仕方がない」と許容されている部分があるようにも感じます。照査時に V&V を要求している会社も少ないでしょう。
（照査以前の問題ですが、解析を知らない executives が解析業務を照査して見逃しを生むような危機感のない会社もありますし、適当な報告書を出している会社も散見します。V&V のような考え方に至るまで程遠いのが実情かもしれません。）

ミスをなくすためにどこまでやるか？
最終的には先日のように同じ計算を異なる手法で実施しないと駄目でしょうね。長期的経営に危機感を持つ会社、力を入れている会社の取り組みは照査内容も一味違います。

8年前の資料ですが、JAXAさんから V&V を独立した第三者で実施するためのガイドラインが出ています。
https://jaxa.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=4174&item_no=1&page_id=13&block_id=21

土木分野では、設計・施工別発注により事業全体を通し設計ミスを見逃さない仕組みはできているともいえるでしょう。さらに、施設の重要度に応じ IV＆V に似た仕組みをお客様側でも取り入れていただくことで各段階のミスを早期検出できるでしょう。
いずれも時間と費用が必要な、マネージメントとしての判断・対応になります。

 

データチェック

なぜか結果が合わない、ということで原因を探りに探ると、出発点のデータにミスが見つかりました。

決定的だったのは、データの一部に異物が混じっていたこと。日本全国、30年強のデータの中の数日分が異なっていても、なかなか気づくことはできません。

結果が合わないと気づいたのは、異なる手法で２回計算したことによります。
以前はチェックに可視化が有効でした。が、最近は可視化すら難しいデータ数になりつつあります。今のところ、チェックするには異なる手法で2回計算するしか思いつきません。計算過程のチェックだけではダメ。大量データの組み合わせなど、全ケースを想定できるほど賢い頭を持っていませんので。

時間のない中、大量のデータの加工からやり直しとなると、数年前では絶望的でした。今は何とかリカバリー可能です（たぶん）。個人的にも処理能力は数段上がったと思います。が、処理能力が上がると、それに応じて負荷がかかる状態。いつの時代も変わりません。量的な生産性向上のみではダメなのでしょうね。

もう少し、頭を使ってみましょう。