脅威の学習

韓国に負けるし、花粉症は激しいし、選手権は目前だしで、
ブログ書いてる場合じゃないですが(^^;

位置評価はそれなりに学習できるってことで、
最後の砦は「脅威学習」なわけですが、

type0は味方利き>敵利き
type1は味方利き＝敵利き
type2は味方利き<敵利き
駒は守り金で、場所は2+2*9の後手王の周囲

type:0
 +9  +0 +37
+39  +0 +142
+143 +141 +143
+139 +143 +125

type:1
+131 +38 +139
+124  +0  +0
+132 +142 +139
+127 +63 +145

type:2
+141 +117 +141
+140  +0  +4
+121 +133  +5
+108 +142 +143

本来ならtype2はピンチなので、type0やtype１より守り銀の減点がきつくなってくれないと困ります。
あと縦方向も、後手王の下より上の方が減点がゆるくなってくれないと困ります
横に関しては、これは右端なので、右より左側が減点がきつくならないと困ります

ってことで眺めると、後手王の左上に関しては、type2>type1>type0でおおむね良いのですが、
後手王の左下は、むしろ逆転している(^^;
ここが攻めの急所と思うので、むしろ重要ポイントなのに……
全体的にかなり微妙な値
しかし、Jは下がるので頭が痛い……

もう脅威の学習はあきらめて手動で行くか？

配列の境界チェックは重要

コンパイラ言語の危険なところは気づかないうちに配列境界を越えることですね
これが配列を超えてコードを壊してくれれば暴走するので気づくんですが、
怖いのは、隣の違う配列の値を参照してたり、書き換えてたりする場合。

この配列が学習要素だったりすると、一部が変なだけで全体ではJは下がったりすると
さっぱり気づかなかったりします。
危険なのが、途中から配列の要素を広げたり小さくした場合で、
修正したつもりが、部分的に境界超えのコードが残ってたりします。

この前のCSA例会で、GPSの金子さんのスライドに
地味ですが、配列宣言時に境界を与えて宣言して、境界チェックもできる手法が１ページありました。
転ばぬ先の杖で、こういうことが実はたいへん重要なのではないかと思います。
普通のC言語的なアプリでも、
配列参照の部分は境界チェックのASSERTを入れまくれば同じことはできるんでしょうけど、
得てして面倒なので、手を抜いたりしますので、
人間は信用できません。強制的にチェックできる仕組みを入れることは大切でしょう。

きっと、misakiにはまだどこかに配列境界越え参照が残っている……