aian さんはインスタンス mstdn.jp のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

aian @aian@mstdn.jp

0/1だけの方形波に対する効率的な巡回畳み込み演算を考えられるだろうか。ウォルシュ変換は、区間[0,1)において、f(t)が可積分であることが必要だけど、まあこれは大丈夫か…。

この点、多くの図面画像が疎に描かれていることが多いことを利用すれば、データ構造(2次元)は疎行列と同様の持ち方をすればいい。同時に、問題としてRWの性能が出てくる。これ以上はちょっと話しづらくなってくる。

図面解析系のアプリケーションは、とにかく時間との勝負になることが多く、それはとにもかくにもファイルがデカいからだったりする。単純に読み込むと、長辺が18Kピクセル超のファイルなどもザラにあるので、単純にメモリに展開しているとあまり大したことはできない。この点からして、ひとつの工夫が要る。

そもそも、図面解析とは何をするのか。機能レベルでいうと、スキャンしたラスタ画像の図面に対して、主に次のようなことをする。
・各種ファイルの読み込み
・ノイズ除去(青焼き印刷なども含む)
・歪みの正規化
・線種の認識
・各コンポーネントの認識
・OCR
・数値とコンポーネント(寸法線など)の紐付け
・ベクタライズ
ここら辺までが基礎機能。この上に、アプリケーションごとに付加機能を開発する。

図面解析系のプログラムを少しまとめているんだけれども、この分野はほとんど完全にブルーオーシャンなので、先行事例がない。既にできることはあれこれあるんだけれども、ユーザの動きを想像できないところがあって、ちょっとUIや提供方式をどうするかで悩んでいる。

科学的事実は、作法に照らして検証できることから分かりやすい。一方で、裁判所がするような事実認定は、証明自体が歴史的証明なので、かなり微妙な話になってくる。

ファクトチェックの自動化とゆのは、なかなか大変なことであるよな。そもそも、事実ってなんだよ?とゆ話で。

機械学習の技術屋さんも、自分の古巣であるソフトウェアデザイン方面に引き寄せて、現物を作ることに主眼を置いた方がいいと思うんだけど、理論方面に引きずられる傾向があって、それなら学校に行って学者になった方がいいとは思うんだよね。ここで書くようなことでもないけど。

オブジェクトの復元と背景テクスチャの推論とゆのは、人間的に見て同じようなことをしてるように見えるけれども、機械の処理としては別物として取り扱った方がいいと思う。同じ枠組みで取り扱うこともできるんだろうけれども、注目しているコンテキストが違うので。

その意味で言うと、状態グラフとゆよりは、依存関係グラフ(dependency graph)の枠組みとして捉える方がいいことになるのか…。なんか、結局make(1)を作ろう!とゆところにまとまってしまう感じなんだが…。いずれにしても実装パターンは考える必要があるのかな。

Stateパターンは、各状態をStateクラスとして抽象化できる程度にまとめられる処理を問題にしている。例に挙げた引数の解析と画像の前処理なんかは、それらだけ取ってみると、特に抽象化できるわけでもない。もちろん、無理矢理基底クラスを定義すれば、形だけStateパターンとして成り立たせることはできるけれども、結局、個別のステータスやパラメタが増えることになり、ダウンキャストの嵐になってしまうと思う。このアプローチはおそらく違う。

んー…しかし、これではないなぁ。

字面通りに「状態制御」と捉える場合、対応するパターンがないわけではなく、いわゆるStateパターンとゆもんが提案されてはいる。Contextと呼ばれるクラスが、各「処理」を抽象化した関数オブジェクトを選び取って実行していくパターンになる。この文脈でいうなら、あたしが問題にしているのは、このContextクラスの実装パターンとゆことになると思う。 ja.m.wikipedia.org/wiki/State_

この点、関数型言語の処理モデルでは、各関数の結果(これらは副作用であることが多い)に依拠しないで、計算を進めていくのが基本のように思う。けど、さすがにこれは実装の点で小回りが利かない感じがしている。

先日、関数オブジェクトを木構造に構成した上で、行きがけないし帰りがけで処理するようなモデルをTwitterに書いたけれども、可読性や保守性の点で、まだ改善したとは言えないと思っている。特に、ある種の処理を通って成功/失敗したとゆ結果をどのように持ち続けるか、とゆ点で、まだ煮詰まっていない。

実際はもう少し事情が複雑で、オプションによって、途中まで一緒だけど後で処理が別れる、とか、入口は違うけれど出口は一緒、のように、一本道ではないグラフ構造になる(状態遷移グラフ)。ここら辺を統一的に取り扱えるようなパターンが欲しい。

内部的な状態制御とゆのは、具体的に言うなら、例えば、コマンド引数の解析をしてから、参照先パスの画像をメモリに展開し、それに前処理を施した上で、ゴニョゴニョやり、出力先に出力する、のような一連の処理において、「引数を取得した状態」や「前処理した状態」のように状態が変化するわけで、そいつを系統的に制御したい、とゆ話。

考えてるパターンとゆのは、バッチ上の処理を行うごとにプロセスの状態が変わっていくようなモデルにおいて、どうやってその状態を管理するか、とゆ問題。フラグ制御のようなもんがあり得るけれども、これはどの段階でどのようにフラグが変化するか、プログラム外で決めておかないといけないし、フラグが変わるタイミングについても繊細な取り回しが必要になってしまう。こゆ設計は保守性が極めて悪く、チームに入りたてのメンバーが開発に入るや否や、簡単に壊れる構造になりがち。

バッチ処理のパターンについて、何か議論があるかと思って調べている。見たところ、異なるバッチの制御(並列実行の制御とか)等々、タスク制御を問題にしているものが多いようで、ちょっと考えている問題とは違う。考えているのは、ひとつのタスクの内部における、状態制御とゆ方が正確かもしれない。