Local Optima

数理最適化を趣味的に楽しむ。

数理最適化プロジェクトのリポジトリ構成・プログラム設計

調査したところ、ふーんなるほどなと思ったので書き留めておくものです。

数理最適化プロジェクトにおけるリポジトリ構成、プログラム設計はいかにするべきかという話題です。

読み物

3つ紹介します。まずはこの書籍。

gihyo.jp

数理最適化に限らないデータサイエンス全般のプロジェクトを念頭に、環境構築・リポジトリ構成にはじまり、品質管理、プロトタイプ開発に及び幅広く論じられています。

zenn.dev

こちらは数理最適化のプロジェクトを念頭にリポジトリ構成について論じられています。

qiita.com

こちらは数理最適化プログラムの実装場面におけるクラス設計について論じられています。 クラスにはするけれども、完全なオブジェクト指向にはしないとのことです。

なぜこんなことが話題に上るのか

数理最適化エンジニア(もしくは研究者)は、モデルの構造とか定式化の強さとか求解アルゴリズムに詳しくても、 得てして、プログラムの設計・コーディングに及んでまで百戦錬磨のプロフェッショナルであるわけではないことが多いです。

これ自体は、数理最適化それ自体の、プログラミングの外側の領域にある専門知識の必要性を反映してのことでしょう。 実際、数理最適化用のライブラリ(gurobipy、PuLPpython-mipなど)それ自体、数理最適化の前提知識なしにはリファレンス・マニュアルを読むことすら難しいと思います。

では、数理最適化エンジニア(もしくは研究者)が、数理最適化アプリケーションのスクラッチを作るとどういうことが起きるかというと、 これは私自身の経験や戒めを含めて申し述べるのですが、

  • Notebook上では動いてもAPIになっていない
  • ろくなテストがない
  • スパゲッティコードが出来上がる
  • コードとパラメータが密に結合している
  • コードとパラメータを分離したつもりが、どれがデフォルト値で最終的にどれが使われるのか分からなくなった
  • もはや正しい仕様がよく分からない

とまあこういうことになるので、適切に教育訓練が施されたりチーム編成〔役割分担)がなされたりするわけです。

数理最適化システムベンダーは筋が悪い(のではないか?)とかいう言説もあるわけですけど、似たような話で、①数理最適化だけができるエンジニアではベンダーにいても1人じゃ稼げない、②自社開発エンジニアができる人は数理最適化以外の仕事があまりに多くてそれどころじゃない ということになるのでしょう。

数理最適化エンジニア(もしくは研究者)はソフトウェアエンジニアリングを学ぼう

数理最適化モデルを実装したり改良したりテストする工程は数理最適化エンジニアにしかできないし、それ自体が至高の喜びなんじゃないでしょうか。 論文や仕様書に定式化を書き下すだけでは面白くないでしょう?(それ、動くか確かめた?)

そういうわけで、数理最適化エンジニア(もしくは研究者)も多少のソースコードをこしらえることになるわけですが、 それって数理最適化エンジニアではない誰かと育てていかなくてはいけないフェーズが来るものです。

その引き継ぎをスムーズに進めるためにも、最初の出発点(リポジトリやクラス設計)がきれいで整頓されたものであることが必要になります。 よって、数理最適化エンジニア(もしくは研究者)は、ソフトウェアエンジニアリングを学びましょう!

これは、(ソフトウェア系ではない)各固有技術領域から、業務上その他の理由で数理最適化に入門することになった方に、特に強くお伝えしたいことです。

数理最適化の周辺領域

数理最適化プロジェクトには数理最適化技術の周辺でいくつかやることがあるはずです。 この時代、数理最適化だけじゃプロジェクトは完結しないものです。

  • データの集積
    • そもそものデータを望ましい形で集めてくること
  • 前処理
    • 集めたデータが数理最適化モデルの係数とか定数にすぐなるとは限りませんからね
    • 単にデータを整形するだけではなくて、統計解析や予測アルゴリズム機械学習に通すこともありますよね
    • 固有技術に特有のデータ形式もあるかもしれませんが、ソルバーに乗るようにしなきゃいけません
  • 可視化
    • 入力データがユーザーの意図しているとおりに作られているか
    • 最適化の結果がどうなっているか
    • これらを、非専門のユーザーにわかりやすく伝える必要がありますよね
  • バージョンアップ
    • 変化の早いこの時代です。
    • 付き合っている業務プロセスや固有技術の変化や進歩に出遅れてはいけない
    • つまり数理最適化システムのメンテナンス性が重要

大きいベンダーだといざ知りませんが、周辺領域まで含めて極少人数 or 1人屋台でやらされて大変な目に遭っているケースって見えてこないだけで意外と多いんじゃないかしら。 屋台が潰れないためにも骨太の構造がリポジトリ・クラス・プログラム設計には必要になってくるんだと思います。

平均を取って満足しちゃダメ!

前回、統計を話題にしましたが、ただの愚痴でした。今回は、もう少し具体的な話をさせていただきます。

さて、平均を取って満足していないでしょうか?

平均を取って、満足してはいけません!

算術平均は、母平均に対して不偏な推定量であり、とくに母集団が正規分布に従う場合には最尤推定量を兼ねているという、とても優れた統計量です。これは疑いようもない。だからこそ、いろいろな場面で使われます。

  • 算術平均
    •  n 個のデータ  x_1, x_2, ..., x_n の総和を標本数  n で割った値で、  \bar{x} = \frac{1}{n} \sum_{i=1}^{n} x_i
  • 最尤推定
    • 観測データが得られる確率(尤度)が最も大きくなるように、分布のパラメータを推定する方法で得られる推定量
  • 不偏推定量
    • 定量の期待値が真の母数に等しい推定量、すなわち  E(\hat{\theta}) = \theta を満たすもの。

しかしそんな平均にも、いろいろな落とし穴があるのです。

落とし穴ひとつめ。外れ値に引っ張られやすいことです。 測定がマズかったり、そもそも対象のバラツキのコントロールが未熟すぎたりすると、平均値はすぐに母集団の中心を代表しない値に引っ張られてしまいます。

落とし穴ふたつめ。分布の非対称性(歪み)に関するものです。 よくある例え話ですが、「年収」の分布は、高所得者の外れ値もありますが、ボリュームゾーン中流以下に偏っています。このとき、「平均年収」は必ずしも「中流」を体現しておらず、中流よりもやや大きな値になりがちです。

いずれの落とし穴に対しても、サンプルの分布を直接確認することが大切です。

ヒストグラム はそんなときの強力なツールになります。ヒストグラムを使って、外れ値はないか、測定レンジは適当だったか、分布の形は左右対称なのかそうではないのか、中心が妙に尖っていたり、裾が重かったりしないかを、まず視覚的に判断しましょう。

これらの「きれいなデータ」の要件を満たしていれば、最低限、安心して平均を眺めることができます。

しかし、現実世界から上がってくるデータは、上記の「きれいなデータ」の要件から往々にして外れてしまうものです。

対処方法はさまざまです。平均値のかわりに中央値を見るなど。しかし、これ以外にも、本当にさまざまな方法があります。よって、ここが分析者の腕の見せ所なわけです。

もちろん、非正規分布の当てはめなどをするに当たり、パラメータとして算術平均が必要になるシーンもあり、そういうときは平均を使うこともあります。

ヒストグラムを描いて、算術平均を取るくらい、現行学習指導要領の高校数学IAにも入っていますからね。仕事の道具として統計を使う方は、もう少し高みを目指したいものです。

回帰分析くらいちゃんとやってほしい件

愚痴です。

Excelさえあれば、シンプルな単回帰分析ごときはお手軽にサクサクとできる今日です。 大変便利であり、たいへんおめでたいことです。

一方で、イマイチな単回帰分析が世の中に放たれている事例も散見されます。 これが非常に気になる。

現実から出てくるデータを、とにかく何か分析しないと仕方がない場面もあります。

そして、そういうデータは、往々にして汚い。

分析すると言ったって一筋縄にはいかないから困るものの、そもそも他のなにかに困っているから分析のニーズが上がってきているわけで。 どちらへ進んでも茨の道。

  • 測定の品質が低く、データがノイズまみれ
  • 重要なファクターや共変量が測定できていない
  • ばらつきのコントロールが未熟すぎて、回帰分析をするには早すぎる
  • データの背後にある現象に単純な回帰モデルがそもそも当てはまらない

このような課題に加えて、データの持ち主周辺にも課題がある場合があります。

  • データはあるが分析の目的を見失っている
  • 数理統計学の知識に乏しく、問題に気が付かない
  • 測定技術の知識に乏しく、問題に気が付かない
  • 対象とする固有技術の知識に乏しく、問題に気が付かない
  • 問題には気がついても、原因も有効な解決策もわからず、諦めている
  • 目先の生産性を優先するあまり、必要な知識に到達する機会を失っている
  • 分析に十分な手間暇を掛けられない
  • Excelでは機能が不十分で満足な分析ができないが、かといってほかのツールを使うことはできない
  • 高級な分析をしてもステークホルダーリテラシーが追いつかない

頭が痛いですね。

イマイチなデータ分析の背後にはこれらの課題が多かれ少なかれ関係しているのではないかと思います。 ビッグデータの時代とあって、なんでもよければデータの採集が容易になりましたから、そもそもデータが増えましたし、汚いデータも増えたことで、分析の難易度が輪をかけて上昇していることもあるでしょう。 あるいは、データにリーチする人々が増えたことで、技術力の担保が難しくなっていることもあるかもしれません。

自らの戒めとして、覚えておきたい心構えを書き留めておきたいと思います。

  • 分析の目的を最初からはっきりさせ、しっかり関係者全員の共通認識とする
  • 分析の目的に叶う測定を行う
  • データの背後にあるモデルをよく吟味する
  • データがあるからといって、どんな分析をしてもいいわけではない
  • データ数が多ければいいというわけではない
  • 解明不可能な系統誤差をかぶるくらいなら、思い切ってデータを絞り込む
  • そうはいっても無闇にチェリーピッキングをしては決してならない
  • Excelは便利だが、なんでもかんでもExcelで事足りるわけではない
  • 性急に結論を出さない

頭ではわかっていても、どうにもならないこともあるんですけどね。

PythonでGUIとCUI両対応の業務ツールを開発したい

業務ツールみたいなものをサクッと作りたい。 テンポラリに業務に携わる人もいるので、それなりに親切にGUIをつけてあげたい。 しかし長く携わる人にはGUIがないと何もできないというのでは却って手間になる。腱鞘炎になるほどに。 GUIでも使えるけど、バッチ処理で多数の処理もラクにこなせるようにしたい・・・。

つまり、GUICUIを両方用意しておきたいということです。 さらに実務上は、それを 少ない手数で 用意したい。

そんなときどうしたらよいのでしょうか。開発言語はPythonとします。

このような課題を、ぼんやり考えていても糸口が掴めないので、とりあえずChatGPTに聞きながら調べてみました。本記事には途中、Pythonコードも出てきますが、動作確認はしていませんのであしからず。

続きを読む

自動車学校 12号車の思い出

十年くらいまえに、普通免許を取るべく自動車学校に通ったときの記憶である。MTで教習を受けた。

教習車は昔ながらの(?)、角ばったトヨタのクラウン・コンフォートである。MT教習車が1号車〜で白いアンドン、AT教習車は50号車〜で黄色いアンドンと区別されていた。

かといって車台がものすごく沢山あるとかではなく、MT車が5〜6台くらいと、AT車が十数台だったか。欠番もよくあった。

当時、1号車と3号車は、パワーウィンドウ付きで、コックピットライトも白色LEDの、新しいクルマだった。教習にも優先的に割当てられていたように思う。

それで、すこし思い出があるのが12号車だ。

12号車はちょっと古くて、マドがハンドルをぐるぐる回すタイプの手動だった。 それだけなら大した問題ではないのだが、エンジンが若干ノッキングしやすかったんである。

アクセルの遊び(不感帯)も、やや独特の踏み心地で、他のクルマと操作感がだいぶ違っていた。少しパカパカした印象を与えるものだった。

たしか6号車も、手動ウィンドウの古めのクルマだったけど、状態は悪くなかった。とにかく12号車だけが、運転しにくいハズレだった。

もっとも、12号車に当たる頻度は稀だった。だから大抵の教習には難はなかったし、当たったときだって多少ギクシャクしながらも、教程をパスすることはできていた。

しかし、検定とか、高速教習のような、大一番で当たってはいやだなあと思って心配だった。教官にも言ってみたが、どのクルマが当たるかは直前まで分からないということだった。

結果的には、そのような大一番に12号車が当たることはなかった。検定も高速教習も、1号車か3号車かだったような気がする。実態としては、整備状態のよいタマを優先的に充てるようにはなっていたのだろう。そしていずれも無難に合格することが出来て、ホッと一安心。

ところで相手の教官は、言ってみれば、みな運転は教えるほど上手いんである。多少ノッキングしようが、アクセルペダルがパカパカしようが、大して気にはならなかったのかもしれない。

FF10の「ベベル」を考える

前回に続き、ファイナルファンタジーXに登場する都市についてまったり考察する。

ベベルの概要

ベベルはスピラ最大の都市であり、エボン寺院の総本山(聖ベベル宮)が座す。海上に築かれた都市とゲーム内で説明される。 都市構造として、ベベル都市主要部は内陸から「グレート=ブリッジ」を隔てている。「グレート=ブリッジ」からベベル内部へは大門があり常に僧兵が監視している。

ゲーム内では、ベベルの都市のほとんどのエリアに立ち入ることはできず、都市の様相としては不明な点も多い。続編のFF10-2ではベベルの立ち入れる範囲が若干広がり、聖ベベル宮に向かう通路や宮殿内部に入れるが、都市機能を推し量るには足りない。

聖ベベル宮

聖ベベル宮はエボン寺院の宗教的役割の総本山であるとともに、スピラ中の小国家を束ねる社会的中心地でもある。司法の機能を持っており、ゲーム内では主人公の一行が、殺人の罪を犯した「反逆者」としてベベルで裁きを受けるシーンがある。

また、聖ベベル宮には「試練の間」「祈り子の間」があり、召喚士の旅の一目的地としても極めて重要である。しかし、一般市民の礼拝を行うような大広間の存在は、ゲーム内の他の寺院と異なって描写されていない。

神官用通路には、対外的な教えに反し、機械装置が設置されている。

聖ベベル宮の防衛

エボン寺院は僧兵を有しており、ベベルでは敵キャラとしても登場する。

前回取り上げたルカは、討伐隊が街を『シン』から防衛していた。一方、ベベルでは『シン』に対する防空として、「エフレイエ」という魔物を寺院が放っている。ベベルの海上防衛がどのような体制であるかは、作中で言及がないが、僧兵が担っているのではないだろうか。討伐隊はエボン直轄ではない武装組織ということでクーデターのリスクを抱えることになるため、ベベルには置かれないものと思われる。後述のように、エフレイエの姉妹品のような魔物が水中に棲んでいるため、海上防衛も同様にエフレイエが担っている可能性がある。

浄罪の道・浄罪の水路

罪人を処分する場所である。放り込んで野垂れ死ぬのを待つ。なぜか出口はある。

浄罪の水路は水中のダンジョンであり、海上都市ベベルの地形を活かして構築されていることが作中でも示唆されている。ボスとして、「エフレイエ・オルタナ」が待ち構えている。エフレイエ・オルタナはゾンビ状態の敵である点が特筆される。

ベベルの海運

前回述べたように、エボン一行がルカに船で訪れるシーンが作中にある。ベベルに港があるという描写は直接的にはないが、港がある可能性は高い。

FF10の「ルカ」を考える

2001年発売のゲーム「ファイナルファンタジーX」(以下、「FF10」)に登場する「ルカ」という都市について、いくぶん都市工学的に考えてみよう。まあ、ファンタジーの世界のことなので肩の力を抜いて書く。

背景

FF10の舞台となる世界は「スピラ」と呼ばれている。いくつかの民族が知られていて、所々に小さな都市国家のような街を形成している。(これ自体はゲームの世界としてはありきたりの設定である。)世界の大多数の都市国家およびその人口は「エボン寺院」という宗教組織によって束ねられ、規律が保たれている。スピラには1000年前に巨大な魔物『シン』が現れ、以来、機械文明で栄えた都市は『シン』によって破壊を繰り返されており、ほとんどの都市国家の規模は小さいままである。街道の要衝や離島にエボン寺院が構えられていて、地方の宗教基盤として機能している。

現在の「スピラ」の世界の大都市と言えるのは、エボン総本山の構える臨海都市「ベベル」(海の上に築かれたと物語中で説明される。)と、同じく海に面している「ルカ」の2つである。『シン』出現前は、北方の「ザナルカンド」や、中部の河川橋上に築かれた都市があったことが物語中で確認できるが、いずれも1000年前に『シン』に破壊されて以後、都市としては再興されておらず、遺跡が残存しているのみである。

エボン寺院は、『シン』を人間の罪が具現したものであると説き、機械の力に頼ることを悪として禁じている。そのような戒律の敷かれた世界において、人々の娯楽は「ブリッツボール」という水球に似た球技(の観戦)である。

「ルカ」の概要

ルカは大陸の南端に位置する港町であるとともに、世界で唯一のブリッツボールのスタジアムを擁している。ベベルに次ぐスピラ第二の都市である。ルカからは北方に「ミヘン街道」が伸びており、別のいくつかの街道を経てベベルへ通じている。南方は離島「キーリカ」に連絡船で結ばれている。

ルカへ結ぶ航路の存在

また、ルカにエボン幹部一行が航路でやってきたことから、定期か不定期かはさておき、ベベルとも航路で結ばれているものと考えられる。なお、ベベルも「海上の都市」として説明されていることから、海運の便はよいのであろう。

ルカの港は1~8番ポートを備えており、その規模からはその他の行き先への航路があってもおかしくないように思われるが、相応しい都市があるようにはゲーム内では描写されていない。

ルカの防衛

『シン』に襲われるリスクを抱えているが、討伐隊という軍事組織が『シン』を追い払って防衛していることが物語中で説明されている。したがって、ゲームのマップ中にそのような描写は確認できないが、ルカには討伐隊の基地のようなものがあって然るべきではないかと思う。

また、『シン』は海中にいたり空を飛んでいたりするため、海洋の防衛が重要である。よって、ルカのポートのいくつかは討伐隊の用に供されている可能性がある。

ルカの人口

ルカのポートには多くの物資が積み上げられている場所もあることから、旅客輸送が行われているだけでなく、海運業の拠点としての機能があると考えられる。また、ブリッツボールの試合中は多くの観光客も訪れることから、観光都市としての性格もあると考えられる。それだけの都市機能を支える基盤として、当然労働人口が必要となると考えられる。しかし、スピラ第二の都市という割には、住宅地のようなエリアの描写に乏しい。ルカ到着時のムービーの一幕に、南側のブリッツスタジアムを臨んで手前側に市街地が描かれている場面がある。そのエリアがルカの商業的機能や居住地としての機能を有している可能性がある。

ルカの行政

ルカは都市の規模こそ大きいが、治安はそこまで悪いような描写はない。よって、何らかの組織が行政的機能を有しているものと思われる。しかし、ルカの地にはエボンの寺院は存在せず、その候補から外される。また、討伐隊が『シン』からの防衛のためにルカに屯する可能性が高いが、行政的な機能を有しているという描写は見られない。ルカの行政的機能の担い手がどのようであるかは、根拠に乏しくはっきりしない。

ルカの報道機関

ルカではブリッツボールの試合中継などを行っている報道機関があり、カメラマンやレポーターの姿がゲーム中にも見られる。ニュースの配信や世論形成にどのような影響力を持っているかははっきりしない。民主的社会が形成されていることを示唆する可能性もあるが、ブリッツボールの報道姿勢はルカのチームを偏重している様子が見られることから、断言するには至らない。

ルカにエボン寺院がないのはなぜか

エボンはキーリカ島やビサイド島のような離島にも寺院を構えている。しかし、ルカの近辺には寺院がなく、海路でキーリカ島の寺院に行くか、陸路でミヘン街道、キノコ岩街道、ジョゼ街道を経てジョゼ寺院に行く必要がある。ルカ市民を含むスピラの民には一部を除いてかなりエボンの教えが浸透していることが描写されているのに、ルカにはそれを支える施設が見当たらないのがやや疑問である。

おわりに

以上、もう20年以上前のゲームに出てくる街のようすについていくつかの考察を行った。表現に限りのある中でFFXというゲームは世界観をかなり丁寧に描写したが、登場人物のヒューマンドラマを通じてであった点は否めない。FFXの物語それ自体はかなり完成度が高く、人気も高いが、マップそのもので更なる表現の余地はあったのかもしれない。