ペナルティ調整中

id:ak11さんやid:issei_yさんがペナルティの工夫を書かれてましたが、
うちも強めて学習中。
手動の終盤位置評価＋学習位置評価で行きます。

いったん、評価値の絶対値を集計してそれを原資にやってみたんですが、
なんかJ’が下がらないので、いったんやめました。
bona4のソースには、calc_penaltyとして、評価値の絶対値を合算して学習した手で割って
penaltyを計算する部分があるんですが、画面表示しているだけで、
とくにプログラムでは使ってないようなんですよね。

	penalty = calc_penalty() / obj_norm;
	target  = ( pdata[0]->target + target_out_window ) / obj_norm;
	objective_function = target + penalty;

double
calc_penalty( void )
{
  uint64_t u64sum;
  int i;

  u64sum = 0;

#define Foo(x) u64sum += (uint64_t)abs((int)x);
  GO_THROUGH_ALL_PARAMETERS_BY_FOO;
#undef Foo

  return (double)u64sum * FV_PENALTY;
}

targetは探索中にwindowにはっていた値で、outはwindow外。
目的関数はJと思われてるけど、実は、J+penaltyを目的関数と考えている模様。
（元々そうなんだけど、このpenaltyが学習に反映されてないのが謎）

ペナルティ自体は例の

  if      ( v > 0 ) { dv -= (float)FV_PENALTY; }
  else if ( v < 0 ) { dv += (float)FV_PENALTY; }

結局、これって頻度を見ずに値があれば一定のペナルティってことで、微妙ですよねえ
値によってペナルティをかけると値が一定に潰れるから良くないんでしょうけど、
フラグしか見てないのがミソで
これで上手く行くのが謎なんですが、fv.binを後から正規化するプログラムとかが別にあるのかなあ？
処理自体はコメントアウトされてるけど、-10000〜10000に要素の値を抑えようとした形跡がありますね
実際は32で割るので312として足されるわけですが、これって終盤の位置評価として足りないし、
序盤の定跡として多すぎるし。

とにかくbona4のpenaltyは謎なので、うちは頻度も見てペナルティをかけることにします。