Week5までに出てきた＠ｔ、＠ｐを列挙してみます。
Week5のex4.mの中です。
@(p)が絡んでいる nnCostFunction.mはnn_params, input_layer_size,hidden_layer_size,num_labels,X, y,lambdaを入力すると
Jとgradを計算してくれる関数となっていました。
nn_paramsはWeek2/3/4でいうθです。
なんとなくですが、nn_paramsがpと↑の式では表記されて
＠(p)でnnCostFunctionでp=nn_paramsはまだ決まっていない状態かなと思いました。
この仮説で他のケースも見ていってみます。
Week5のGradinent Checkingの中です。
同じく@(p)がnncostFunctionに絡んでいるケースです。
直後に来る式は2つのケースでは違います。
ex4.mではfmincgですが、Gradinent CheckingではcostFuncつまりnnCostFunctionに
nn_paramsを放り込んでいます。
このnn_paramsはfmincgとか入ってないので最適化されてなさそう、と思ったので
前後関係を見てみることにしました。
なるほど。
debugInitializationで計算されたθ＝nn_paramsがそのまま放り込まれていますね。
なので最適化されたθでGradinent Checkingしてるというわけではないですね。
nn_paramsがわかっているなら↑の@(p)の式なしにそのまま放り込めばいいのでは、
と思いましたが、構成上この方がいいことに気づきました。
θ+ε、θ-εでθを変化させてJ,gradを計算させたいから@(p)の式が
挟んであると理解しました。
仮説いまのところ当たってそうです。
Week4のoneVSAll.mのヒントにあったものです。
ここでは@(t)がlrCostFunctionに絡んでいます。
lrCostFunctionlmをみてみます↓
lrCostFunctionはtheta,X,y,lambdaを代入するとJ,gradが計算される関数です。
pとtで文字が変わりましたが仮説は同じだと思います。
なんとなくですが、nn_paramsがpと↑の式では表記されて
＠(p)でnnCostFunctionでp=nn_paramsはまだ決まっていない状態かなと思いました。
Week2 logistic Regressionのex2_reg.mの中です。
Cost FunctionRegの中身を確認してみます↓
costFunctionRegはtheta,X,y,lambdaを代入すればJとgradを計算してくれる関数です。
t＝thetaで@(t)が前に来て、t=thetaがまだ決まっていない状態かなと思いました。
つまり、あとはt=theta次第、ということを表しているのかなと思いました。
なんとなくですが、nn_paramsがpと↑の式では表記されて
＠(p)でnnCostFunctionでp=nn_paramsはまだ決まっていない状態かなと思いました。
fminunc/fmincgがどういう機能のものだったかを書いた日記が
あったことを思い出しました。
その中に
＠ｔ（costFunction(t,X,y))のｔはcostFunction.mを呼ぶ機能で
fminuncを使うためにcostFunction.mをラップくるむことができると書いていますね。
tはthetaのｔではないようです。
という文がありました。
まぁ、仮説とも近い気もします。
また気づきがあったら考えてみたいと思います！