sasaharayuugo.net

セットアップ時の角の和の取得法について

人間が認識できる解答に必要な情報を完全に取得するということを考えた時に、クラスタによる取得は不完全だと言わざるを得ないのではないかと思う。
例えば、1つの点から複数の辺が伸びていて、それらのもう一方の端を全て輪のように繋げた図を想像してみる。すると、この時に角の和は一切取得できない。外側のクラスタから見て、真ん中の辺は折れ曲がっていて、素直にクラスタを割った状態になっていないからだ。しかし、人間は角の和を見て取得することができてしまうわけだ。
人間は、平面における辺の並びを見ることができてしまう、また、ポジティブかネガティブかも見ることができてしまう。

やっぱり角の和が曲者で、他は全て自然な取得法になっているのではないかと思う。辺による辺の和と180°の角の和を取得して、平行線(同じ方向の辺)同士による角のイコールを取得して、三角形による色々を取得する、全く合理的であると思う。

なぜ角の和が難しいのかを考えると、辺が反対方向に突き抜けるようになっているからというか、360°で一周するからなのだと思う。もし180°であれば、端と端を登録して、例えば点Aに対して点B、C、D、Eの順番で繋がっているとしたら、[A, [B, C, D, E]]のように登録すれば、角の和を効率的に(また人間がやるように)取得することができる。しかし180°以上のが一つでも交じると、その後側でポジティブな角の和が発生するかもしれず、一気にややこしくなる。

二種類の方法を考えた。
まず一つ目は、さっき書いたような取得法をそのまま使うことで、180°以上のがあるなら、一つの点に対して複数回同じ方法を使う、という方法。
もう一つは、そもそも問題文の角のポジティブやネガティブは最初から不完全な情報であり、人間としても取得しないという方法で、挟んだ辺と一緒に角1や角2という風に名付け、180°以上だと判明し次第ポジティブやネガティブと名付け直す、あるいはそもそも名付け直さない、という方法。

どちらの方法が良いかは分からないのだけど、とりあえず平和的に最初の方を採用することにする。それでまあ問題文の図から角の和を取得することはできるわけだ。
作図をする段階で、なにか新しい角の和の取得方法や解釈が出てくるかもしれない。
クラスタについて考えるのは全く無駄では無かったと思うけど、とりあえず人間が認識できる解答に必要な情報を完全に取得するという観点で、そういうことにした。


これは追記になるのだが、角1や角2と名付ける場合は、まずそれぞれの点において、繋がっている点を循環リストにして、挟まっている点と一緒に機械的に登録していく。その時に挟まっている点が少ない方を角1としても良いし、全く適当でも良い。

で、前者のポジティブかネガティブか判別する方なのだけど、これは点と繋がっている点ごとに、2種類の最大のポジティブが登録できるわけだが、この情報は見方を反転させれば最小のネガティブでもある。その情報を使えば、ネガティブとポジティブでネガティブになる角の和を登録することもできるし、ポジティブとポジティブでネガティブになる角の和を登録することもできる。
いや、ただ、ポジティブとポジティブでネガティブになる角の和の場合、ネガティブな方が最小じゃない場合が漏れてしまうのか?そこはもう少し、凝った仕組みにする必要があるのか…。最小のネガティブな角の和に更に角を追加したものが、ポジティブな角とポジティブな角に分割できるか。


更に追記になるのだが、作図と交点などの確認は考え方としては分けた方が良いかもしれない。作図は定義通りにシンプルに済ませて、確認の方を手間をかけるというかループさせる。

やることと言えば、まず交点を発見する。でもし発見したら、その交点について、辺の和や180°の角の和を登録、平行線で角のイコールを登録、三角形が新しくできてないか探す、三角形定理ループを回す、と最初のセットアップのような動きをする。
違う所と言えば、角の和の発見で、今回のが通用すれば今回のを使うし、通用しなければクラスタを使うことになるかもしれない(クラスタの発見や、クラスタの分割など)。
あとは、不確定なものの確定もする必要がある。具体的には角1や2がネガティブかポジティブか、辺において順番が不確定なものを制約でできるだけ確定させる、などの作業をする必要がある。
(よく分からないけど、それぐらいかな。必要なものがあれば試行錯誤している内に出てくると思うけど。)

3つのステップで一つでも明らかになったら、三角形定理ループみたいにループして、どのステップでも何も明らかにならない状態を目指す。三角形定理ループも別に分けて4ステップにした方が良いかな?