sasaharayuugo.net

クラスタについて

二等辺三角形の作図など、他の作図はわりとハッキリしはじめているのだけど、クラスタの作図はまだ全然なので、その考察をする。

まず、クラスタという機能に何を求めているのか、を考えると、まずはこの問題を解くのにその機能がいる。そして、（２次元上のユークリッド幾何の問題において）角の和について登録する時にクラスタという概念がいる。
前者は場当たり的に満たしていけば良い、つまり、できる限り最小の実装をして、必要であれば機能を拡張していけば良い。
そして後者について考えると、このクラスタには全ての角がp（ポジティブ、つまり2辺でできる2つの角のうちの180°以下の方）じゃないものは加えない方が良いのではないか。

三角形はクラスタ（面のこと）で、三角形の底辺を合わせて、その底辺が耐震構造のバッテンのようになるように交わるように、四角形を作った時に、その四角形はクラスタだと見なせるという話だった（説明が下手くそで申し訳ない）。
三角形の底辺を合わせて、その一方の合わさった角と、それぞれの頂点で三角形を作っただけで良いんじゃないか、と思ったこともあった。しかしその場合だと、もう一方の合わさった角がネガティブな場合もあり得る。それだと角の和を考える時には不都合なわけだ。

問題は、問題文の図を写す時にそれでは記述できない場合があることで、それについてはどう考えれば良いのかな。
クラスタを合体する作図の時には、合わせた辺でできる角の和がそれぞれポジティブであれば良いわけだが。

まあしかし、角の和を考える時に、面を想定する以外に方法ってあるのかな。点と、角と角の向き合い方だけに着目するっていうのが構想というかイメージとしてはあるのだけど。
とりあえず、この方針で行って、他の良い方法を思いついたらその方法を採用するということにしようかな。
いやでも、ネガティブな角を生み出している出っ張りの部分を区切るように線を引いた所で、またできる角もネガティブかもしれないんだよな。問題文での図の表現をそのまま写すということを考えると、やっぱりネガティブもクラスタに含めた方が良いのか？

角の隣接というのがキーになると思うんだよな。足し算による隣接の表現を仮に機能として想定してみるか？
四角形に三角形をくっつけたとして、隣接する点の両方と、四角形を作るような処理ができれば、とりあえず多角形の全ての角がポジティブな面というのは、考えることができるんだがな。それでは問題文の図を写せないという点で問題で。
人間の思考をエミュレートする上でどうするのが自然なのかという問題なんだよな。

結局、問題文やその図が論理的に、それも三次元の問題に適用可能な意味で何を表しているのか、が問題なんだよな。それを十分に汲み取れる形式を考えれば良いわけで。
と考えると、何と何が繋がっているかを表すグラフと、何と何が平面として繋がっていてそれぞれの角が少なくともポジティブかネガティブかを表すクラスタ、また遠隔で何と何が同じかを表す式だけで無く、どの角とどの角が隣接しているかを表す機能も当然必要なんじゃないか（ちなみに三角形のリストはグラフから自動生成できる、が一々自動生成するのは面倒なので空のリストというか辞書は作っておくが）。そうじゃないと意味を十分に汲み出したとは言えないんじゃないか。
じゃあ、やっぱり隣接する角を和で表す機能は少なくとも想定することにするか。クラスタを2種類用意するか、はまだ保留なわけだが。
仮に、「adjacent_angle_lst」、としてみようか。
クラスタは今まで通りの「cluster_lst」と、全ての角がポジティブな「p_cluster_lst」で分けて、統合できそうなら統合するか？そうしてみようか。

adjacent_angle_lstは、cluster_lstで代用可能なんじゃないかなあ。別にどちらでも良いのだろうけど、triangle_lstもp_cluster_lstも全部普通のcluster_lstで扱って、そこから3つだけとか、ポジティブな角だけとかで、抽出してもとりあえず問題は無さそうだがな。
いや、adjacent_angle_lstがcluster_lstで代用できるのかっていうのは怪しいな、やってみないと。

graph、adjacent_angle_lst、cluster_lstの3つで行こうか。

ちょっと今日の考察はあまりにもグダグダで申し訳ないのだけど、問題文の図を純粋に眺めてみると、adjacent_angle_lstと、graphと、角や辺や具体的な数値のイコールだけなんだよな。それらの入力から、triangle_lstはもちろん、cluster_lstやp_cluster_lstも生成できないかな。それをどう使うかは後から決めれば良い話で、そういえば平行線のリストもあるはずだし。

いややっぱり駄目だ、この問題が解けねえ。じゃあやっぱりそれプラスでcluster_lstだな。

graphは今までにもあるし、adjacent_angles（名称変更）も角の和を登録する作業として今までも似たようなことをやっていた。cluster_lstでどれだけ登録する必要があるのかが今悩んでいる所で、外側だけで良いのか、それとも全部登録する必要があるのか、全部登録する必要があるとして自動化できるのか（？）。
いや、混乱している。三角形定理ループを自動化した時の例題で、graphとadjacent_angles（と平行線リスト）でどれだけ立ち上げることができるのか、どれだけcluster_lstが必要なのかを試してみようかと思っている。