円と直線の交点を二つ追加し、その後に円や直線を動かしたときに、二つの点が合流してしまうことがある。
この原因を探っているのだが、一応わかった。
（１）実数根と虚数根のやりとりにおける「右回りアルゴリズム」には破綻はなかった。むしろよく動いているとさえ言える。
（２）交点が二つある状態で、直線の動き具合によって、「もっとも近い点」ではうまくいかないことがわかった。つまり、点A,Bが点A',B'へ行くべきのところ、Aから見たもっとも近い点がA'であり、かつBから見たもっとも近い点もA'である、というような図がありうるのだ。これは、偏角を用いても解消できない。
この原因を探っているのだが、一応わかった。
（１）実数根と虚数根のやりとりにおける「右回りアルゴリズム」には破綻はなかった。むしろよく動いているとさえ言える。
（２）交点が二つある状態で、直線の動き具合によって、「もっとも近い点」ではうまくいかないことがわかった。つまり、点A,Bが点A',B'へ行くべきのところ、Aから見たもっとも近い点がA'であり、かつBから見たもっとも近い点もA'である、というような図がありうるのだ。これは、偏角を用いても解消できない。
今ちょっと考えているのは、角AOBと角A'OB'が必ず０～１８０度の間に入るようにA',B'をつけかえる、という方法。
（８月２７日あはら）
（８月２７日あはら）
かなり試行錯誤したが、どうにかなったようだ。結局、「もうひとつの交点」の座標をいつも携えることにし、「アイツとワタシ、どっちがフサワシイとおもう？」という感じで査定していったのだ。
具体的には、「その点」を(para1,para2)とし、「もう一方の点」を(para3,para4)とすることにした。
これなら、実数根が虚数根に変化するところも明快に記述できる。実数根の小さいほうが、虚数根の下のほう（虚部がマイナス）へ動くことに決めている。
「いやな図」のパターンがいくつかあり、それを全部クリアすることを考えなければいけなかったのだ。
これらは、GConst::Evaluate()のcase CONST_MEET_CLで実行される部分だが、まず、新しい交点を二つ求めて、それを(xx1,yy1)と(xx2,yy2)とする。ここまでは前と同じ。
（場合１）xx1もpara1も実数のとき
これは、いわゆる「点の動き」に対応するのだが、これでも結構厄介な場合が多い。つまり、たとえば(xx1,yy1)と(xx2,yy2)の両方が(para1,para2)の近くにある場合、うっかりどちらと決められないのだ。(para3,para4)から見て遠いほうが、正解である。しかし、あまり場合わけが煩雑だと、時間がかかってしまうので、そこを簡潔にまとめた。
（場合２）para1は実数で、xx1が実数でない場合
これは「点が消える」状況だ。para1とpara3とを比較して大きいほうが上半平面へと移るようにする。
（場合３）para1は実数でなく、xx1が実数の場合
これは「点が現れる」状況だ。もしpara1が上半平面にあればxx1とxx2とを比較して小さいほうへと移るようにする。
以上。
具体的には、「その点」を(para1,para2)とし、「もう一方の点」を(para3,para4)とすることにした。
これなら、実数根が虚数根に変化するところも明快に記述できる。実数根の小さいほうが、虚数根の下のほう（虚部がマイナス）へ動くことに決めている。
「いやな図」のパターンがいくつかあり、それを全部クリアすることを考えなければいけなかったのだ。
これらは、GConst::Evaluate()のcase CONST_MEET_CLで実行される部分だが、まず、新しい交点を二つ求めて、それを(xx1,yy1)と(xx2,yy2)とする。ここまでは前と同じ。
（場合１）xx1もpara1も実数のとき
これは、いわゆる「点の動き」に対応するのだが、これでも結構厄介な場合が多い。つまり、たとえば(xx1,yy1)と(xx2,yy2)の両方が(para1,para2)の近くにある場合、うっかりどちらと決められないのだ。(para3,para4)から見て遠いほうが、正解である。しかし、あまり場合わけが煩雑だと、時間がかかってしまうので、そこを簡潔にまとめた。
（場合２）para1は実数で、xx1が実数でない場合
これは「点が消える」状況だ。para1とpara3とを比較して大きいほうが上半平面へと移るようにする。
（場合３）para1は実数でなく、xx1が実数の場合
これは「点が現れる」状況だ。もしpara1が上半平面にあればxx1とxx2とを比較して小さいほうへと移るようにする。
以上。
