WEBVTT 00:00.180 --> 00:02.070 こんにちは､ このチュートリアルにようこそ｡ 00:02.290 --> 00:06.060 さて､ それではエントロピーを計算し､ エントロピーリストに追加しました｡ 00:06.060 --> 00:12.660 そして､ これから行うのは､ 集合maxの確率分布にしたがって､ ランダムに行動を抽選することである｡ 00:12.990 --> 00:14.460 では､ こうしてみましょう｡ 00:14.460 --> 00:15.590 それが次のステップです｡ 00:15.600 --> 00:19.840 私たちはまだここのステップで走っているので､ ループの中にいるのです｡ 00:19.860 --> 00:22.370 というわけで､ アクションの遊び方はお分かりいただけたと思います｡ 00:22.380 --> 00:28.560 まず､ actionという行動を表す変数を導入し､ 確率の分布を取り､ 00:28.560 --> 00:38.340 この確率の分布から多正規関数を使ってランダムに抽選を行うことにします｡ 00:39.030 --> 00:41.210 そして､ そのデータを追加していくのです｡ 00:41.220 --> 00:47.610 そこで重要なのは､ アクションが実際には1つの値しか持たないテンソルになることです｡ 00:47.610 --> 00:50.820 しかし､ これを単純な値として捉えてはいけない｡ 00:50.820 --> 00:56.940 これは､ アクションのこの値を含む次元のテンソルとして､ 1つずつ見る必要があります｡ 00:56.940 --> 00:59.010 そしてそれは､ 絞り込まれていないからです｡ 00:59.550 --> 01:09.720 今度は､ 同じforループで､ 先ほど再生されたアクションに関連するログ確率を取得します｡ 01:09.990 --> 01:18.000 そして､ ここで計算した以前の対数問題を用いて､ 対数確率を更新しています｡ 01:18.000 --> 01:31.290 そして､ このアクションに関連するログ確率を取得したいので､ 表示されたアクションと1を入力するgatherメソッドを使用するつもりです｡ 01:31.290 --> 01:38.940 第2引数として､ アクションを入力しますが､ これはゲッター関数が要求する変数でなければならず､ 01:38.940 --> 01:43.980 ギャザー関数はテンソル整数でインデックスを作成するだけです｡ 01:44.340 --> 01:44.700 わかりました｡ 01:44.700 --> 01:48.780 これで､ 表示されたアクションに関連するログプロップが取得できたわけです｡ 01:48.780 --> 01:53.610 そして､ 次のステップは､ ここで得たものをリストに追加することです｡ 01:53.610 --> 01:55.500 だから､ その価値を手に入れたのです｡ 01:55.500 --> 01:58.560 それが､ このモデルの出力として出てきたのです｡ 01:58.560 --> 02:00.720 それから､ 丸太の支柱も手に入れました｡ 02:00.720 --> 02:03.900 そこで､ ログプロップリストにログプロップを追加することにします｡ 02:03.900 --> 02:06.810 すでにエントロピーを付加しています｡ 02:06.810 --> 02:09.480 だから､ 私たちはいいし､ 報酬も､ 後から手に入れることができるのです｡ 02:09.480 --> 02:15.060 そこで､ これから値とログプロップスを値リストとログプロップスリストに追加します｡ 02:15.270 --> 02:16.110 こうしよう｡ 02:16.110 --> 02:17.910 私たちは､ 価値観のリストを取っています｡ 02:17.910 --> 02:24.690 append関数を使って､ モデルから返されたばかりの値を追加しているのです｡ 02:24.780 --> 02:25.620 完璧です｡ 02:25.800 --> 02:28.470 それから､ ログプロブも同じです｡ 02:28.560 --> 02:35.700 新しいログプロブを入手しましたので､ ログプロブリストに追加します｡ 02:36.000 --> 02:42.570 そして､ このappend関数では､ ここで計算されたlog propを入力しています｡ 02:43.870 --> 02:44.200 わかりました｡ 02:44.200 --> 02:46.960 そのため､ 私たちのリストは十分に更新されています｡ 02:46.990 --> 02:52.690 さて､ これから行うのはアクションの再生です｡ 実はここで､ この確率分布からランダムに抽選して､ 02:52.690 --> 02:56.440 アクションを選択しました｡ 02:56.440 --> 03:02.530 しかし､ 実はまだ再生していないのです｡ これから再生することで､ 新しい状態に到達し､ その結果､ 新しい伝送を得ることができ､ 03:02.530 --> 03:05.980 再生することができるようになるのです｡ 03:05.980 --> 03:10.270 私たちは､ 環境の中でアクションを演じるので､ 環境を取ることになります｡ 03:10.270 --> 03:17.980 そして､ ステップメソッドを使い､ 内部では選択されたアクションを指定して再生しています｡ 03:17.980 --> 03:25.060 そのために､ ステップ関数が期待するアクションを起こし､ そのnumpyを追加します｡ 03:25.930 --> 03:27.610 しかし､ これが返ってくる｡ 03:28.770 --> 03:42.990 なぜなら､ 新しい状態に到達することで､ 新しい報酬が得られ､ さらに､ ゲームが終了したかどうかを知るための新しい値であるdoneが得られるからです｡ 03:43.350 --> 03:43.710 わかりました｡ 03:43.710 --> 03:48.300 これで､ アクションを実行すると､ 新しい状態になり､ 新しい報酬が得られるわけです｡ 03:48.300 --> 03:50.070 そして､ ゲームとして完成しているかどうかもわかる｡ 03:50.250 --> 03:59.100 そして､ ゲームが終わるといえば､ まあ､ エージェントが何かの状態で立ち往生しないようにするためのものをここに追加します｡ 03:59.100 --> 04:03.780 そして､ そのためには､ 次のようにdarn変数を更新することになります｡ 04:04.650 --> 04:13.890 まあ､ 終わったに等しいか､ ゲームのエピソードがあまり長く続かないようにという条件をつけることになりますね｡ 04:14.190 --> 04:21.900 そして､ メイン関数の中で､ エピソードの長さの最大値を10,000とするパラメータがあることがわかると思います｡ 04:21.900 --> 04:25.620 そして､ 1つのエピソードが1万個以上続くようなことは避けたいと考えています｡ 04:25.620 --> 04:37.470 そこで､ ここにエピソードの長さを追加し､ Maxより大きいという条件を書き込むことにします｡ 04:38.200 --> 04:39.940 エピソードの長さ 04:40.420 --> 04:40.840 これでよしとしよう｡ 04:40.840 --> 04:45.880 そして､ 実は最大エピソードの長さは､ 私たちのパラメータから取得しているのです｡ 04:45.880 --> 04:50.320 そのため､ ここにparams dot params dot max episode lengthを追加しています｡ 04:50.320 --> 04:59.260 つまりこれは､ ゲームが終了するか､ エピソードの長さが設定された最大長（1万に等しくなる）より大きくなれば､ 04:59.260 --> 05:04.780 まあゲームは終了して､ 新しいゲームを始めるということです｡ 05:06.150 --> 05:07.950 だから､ それはあくまで予防線なんです｡ 05:07.950 --> 05:11.550 そして､ 予防策といえば､ もうひとつの予防策を追加することです｡ 05:11.580 --> 05:15.160 マイナス1とプラス1の間で報酬を締め付けることです｡ 05:15.180 --> 05:20.820 ここではすでに報酬を得たが､ 報酬がマイナス1からプラス1の間であることを確認したい｡ 05:20.850 --> 05:29.220 そして､ そのためには､ 単純に､ 最大値をとって､ 報酬のメンをとるということをやって報酬を更新すればよいのです｡ 05:29.310 --> 05:30.780 そして､ 1つ｡ 05:30.960 --> 05:35.670 そして､ ここでは報酬の最小値と1の最大値とマイナス1をとる｡ 05:35.970 --> 05:39.300 そしてそれは､ 報酬がマイナス1からプラス1の間にあることを確認することです｡ 05:40.030 --> 05:40.720 わかりました｡ 05:40.720 --> 05:42.160 そこで､ もうひとつの注意点｡ 05:42.160 --> 05:49.000 そして､ あとはゲームが終了しているかどうかを確認したいのですが､ その場合は環境を再起動します｡ 05:49.000 --> 05:50.500 そして､ なぜ今それを確認する必要があるのでしょうか？ 05:50.500 --> 05:52.870 それは､ 新しい状態になったばかりだからです｡ 05:52.900 --> 05:54.700 新しいトランスミッションを通過したところです｡ 05:54.700 --> 05:59.410 そこで､ ゲームが終了していない間に､ この新しい送信を通過した後､ 確認する必要があります｡ 05:59.650 --> 06:09.730 ですから､ もしまた行われたら､ その場合はエピソードの長さをゼロにして環境を再起動し､ 06:10.720 --> 06:19.150 さらに状態も初期化して再初期化することになります｡ 06:19.150 --> 06:23.350 環境を整えて､ リセット機能を使うんです｡ 06:24.460 --> 06:24.770 オチ｡ 06:25.060 --> 06:27.360 今､ 私たちはこの状態から脱することができます｡ 06:27.370 --> 06:28.750 それは､ ただの確認作業でした｡ 06:29.020 --> 06:34.420 そして､ これから行うことは､ 新しい状態に達したので､ 06:34.420 --> 06:40.330 まあ､ この新しい状態は､ 今､ そして､ レイによってです｡ 06:40.330 --> 06:44.350 そして今､ 私たちがしなければならないのは､ 新しい状態をトーチテンソルに変換することです｡ 06:44.350 --> 06:52.540 そこで､ 状態を更新するために､ torchライブラリと､ もちろんfrom numpy関数を使って､ 06:52.690 --> 07:01.420 このnumpy配列､ 入力画像の状態をtorchテンソルに変換することにします｡ 07:02.020 --> 07:02.860 完璧です｡ 07:02.980 --> 07:08.560 そして､ このforループから抜け出す前にしなければならない最後のこと､ それは､ ステップのループです｡ 07:08.560 --> 07:12.790 もちろん､ 報酬を報酬リストに追加するためです｡ 07:12.790 --> 07:15.100 それが､ 最後にアップデートすることです｡ 07:15.100 --> 07:18.130 ここでは､ 報酬を除くすべてのリストを更新しました｡ 07:18.130 --> 07:19.450 だから､ 今すぐそれをやるんだ｡ 07:19.450 --> 07:26.830 報酬を受け取り､ append関数を使って直前に受け取った報酬を追加します｡ 07:27.310 --> 07:28.060 完璧です｡ 07:28.060 --> 07:35.230 そして､ ループを抜ける直前に､ それを確認するための最後のチェックを行うだけです｡ 07:35.230 --> 07:39.250 それができているのなら､ 探査を止めたい｡ 07:39.250 --> 07:45.940 つまり､ 探索が終了したら､ 探索を中止して､ 直接､ 次のステップ､ 07:45.940 --> 07:50.890 共有モデルの更新に移るということです｡ 07:51.370 --> 07:54.130 そして､ これでこのforループは終了です｡ 07:54.310 --> 08:03.250 さて､ エージェントは探索を終えたので､ 共有モデルを更新することになりますが､ 次のチュートリアルでその処理を行います｡ 08:03.250 --> 08:04.480 それまではお楽しみに｡ 08:04.480 --> 08:04.990 I.