レンタカーショップ問題（強化学習での行動ポリシー最適化）

    【what is this】強化学習における「状態価値関数」をとりあげてきましたが、今回もその続編です。理論と手法の詳細は参考文献[1]を熟読戴くことにして、ここでは、「レンタカーショップ問題」と呼ばれる複雑な問題がこれに基づいて解けることを楽しみたいと思います。

■レンタカーショップ問題（Jack's Car Rental）
　この問題は著名なSuttonの著作[2]にありますが、簡潔に１ページに纏められており、そこから自分でプログラムを作るのは難しそうです。しかし、中井悦司著[2]では、実に丁寧にこの問題の設定と具体的な解法（Pythonプログラム付き）が解説されており、非常に有用です。このブログ記事は、それにしたがって学んだ結果を小生なりにまとめたものです。

　図１に、この問題の設定条件を示しました。２つの店Aと店Bを持つオーナーが、車貸出しによる利益を最大にするために取るべき行動（戦略）を求めます。その行動とは、営業終了後の夜間に、２つの店の間で適当な台数の車を移動させることです。両店の貸出し/返却の台数の発生確率が異なるため、翌日の営業に備えて、両店の車の台数を調整する必要があるのです。ただし、車を移動することで一定の損失（余分なガソリン代など）が発生します。

　両店の貸出し/返却の台数の発生確率は、ポアソン分布に従っており、その期待値は図１の説明文にあるように分かっているとします。図２に示すような確率分布となります。

■マルコフ決定過程における確率的な状態遷移
　この問題を解くためのベースとなる状態遷移を図３のように定めます。ある時点の状態は、店Aと店Bに現在残っている車の台数のペアとします。営業終了時（午前中は貸出しのみ、午後は返却のみ）の状態をSとします。それに対するアクションa（行動a）は、夜間に店Aから店Bへ|a|台の車を移動させることを意味します。逆向きの移動ではaの値は負値になります。その行動が終わり、さらに翌日の営業が終了した時点の状態をS'とします。つまり、状態Sにアクションaを適用した結果の状態がS'です。

　状態S'では、車の移動による損失と、貸出しによる利益が確率から計算されています。貸し出し／返却台数は乱数で決まるので、図３の遷移は、確率的な状態遷移を含むマルコフ決定過程といえます。この状態遷移をもとに、先の記事でも述べたベルマン方程式を作ることができます。ベルマン方程式を解くことは、各状態の価値（状態価値関数）を計算することになります。

　そして、状態価値関数はアクションaによって決まるわけであり、どの状態に対しても最も大きな状態価値観数値を与えるアクションを求める方法があります。その一つが、ここで使われている価値反復法と呼ばれるものです。

■価値反復法によるレンタカーショップ問題の最適解
　この方法は（詳細はここには書けませんが）、行動-状態価値関数計算とGreedyポリシーの更新と状態価値関数の更新をセットとして、全ての可能な状態（店Aと店Bに残っている台数のあらゆる組合せ）について行います。それを、すべての状態について変動がなくなるまで反復します。反復一回あたり計算量（可能なあらゆる台数についての確率計算を含む）は相当に大きくなりますが、種々の効率化手法がとられます。最終的には、比較的少ない反復回数（数十回程度）で収束解（最適解）が得られるようです。図４は、収束の途中の解（行動ポリシー）を示しています。

　そして、図５は、収束した最適解（最適行動ポリシー）の拡大図です。一つのマスは、一つの状態（店Aと店Bに残っている台数のペア）です。マスの中の数値は、店A→店Bへ|a|台の車を移動するという行動を意味します。この結果を眺めてみて、十分納得ができるように思います。

　全体としては、残っている台数が両店間で偏っている場合は、それを補正する方向になっています。ただし、両店の貸出し台数の期待値（ポアソン分布の）の違いを反映して、店Aから店Bへの移動が多くなっています。

　例えば、店Aに15台、店Bに２台残っている状態では、限度いっぱいの５台を店Bへ移動すべきとなっています。これは、店Bの方がポアソン分布の期待値が大きいことを反映しています。逆に、店Aに2台、店Bに15台残っている状態では、店Bの方が期待値は大きいものの、店Bから１台を店Aへ（少し損失は生ずるが）移動した方が全体の貸し出し数は増えるという判定となっています。

　図５の最適行動ポリシーによる状態価値関数の値を図６に示します。両店にともに車が多く残っている方が、翌日の営業での利益を大きく期待できることを示しており、これも納得できます。

■感想
　冒頭に述べた中井悦司著[1]は、全体で５章の構成、本文全276頁です。今回の話題は、そのうちに第３章（全体の約６割）までの集大成と言えます。つまり、状態遷移を表す条件付き確率が全て計算できる「環境が分かっている」場合の基本的な強化学習理論の結論であると言えましょう。

[参考文献]

[1] 中井悦司：ITエンジニアのための強化学習理論入門、技術評論社、2020年７月
[2] Richard S. Sutton and Andrew G. Barto, "Reinforcement Learning : An Introduction", second edition, The MIT Press, 2018.

MIT App Inventor Summer Appathon（ハッカソン）のご紹介

すでにご存知の方も多いと思いますが、簡単にご紹介致します。

https://appathon.appinventor.mit.edu

このハッカソン（Appathonとなっていますが）、名称の通り、MIT App Inventorを利用します。この開発環境には、各種Webサービス連携、データベース機能（CloudDB, FirebaseDB等）、種々の組込みセンサや外部ボードとの連携（シリアル、BLE等）、豊富なGUIやメディア機能、JavaやJavaScriptの呼び出し、等々が標準装備されています。さらに、多彩なExtensions（特に機械学習関係、Unixコマンド使用、等々）も続々提供されています。

大学でのセミナーや卒研レベルにも有用かと思います。下記の通り、混成チームもありですから、この沈みがちな時世に、教員と学生が絆を深める（強める）機会として共同で挑戦と言うのもありそうです。

他のコンテストなどと同様に、創造的発想が重視されますが、それを実現したスマホアプリの提出が必須です。審査員は、提出されたソースコードを可能な限りビルドして動作を確認するようです。もしも、使用される外部デバイスなどを用意できない場合は、（提出必須の）ドキュメントと動作ビデオでも審査されるようです。

ハッカソンなので、開発期間はテーマ開示後2週間です。（ただし、昨年度のテーマや入賞作品を参考に、事前準備はある程度可能でしょう。）子供/大人、個人/グループ（子供大人混成含む）などのトラックがあります。例年、世界各国からかなり多数のエントリがある一方、最終的に完全な提出まで漕ぎ着ける人はそれほど多くはないようです。かなりキツそうですが、それだけにやり甲斐があるでしょう。当然ながら、未発表作品に限られます。

入賞作品はMITのサイトに大きく掲載され、世界中の人に認めてもらえるという、本来の姿の栄誉を受けられます。（入賞賞品は特にありませんが）純粋に創作活動を讃える場のように思います。

（補足）--------------

えっ、冒頭の説明があってもなお、App Inventorではもの足りない？ (^^ゝ

Really? Then you are a true professional. But don't you find the following few applications that work with Java and JavaScript helpful? :-)

●例１→かなり複雑な計算を含む処理にはJavaを使う。

既存のJavaコードをブロックから呼び出す例は以下にあります。

App Inventor for Android で SVM（サポートベクトルマシン）分類

https://sparse-dense.blogspot.com/2018/12/app-inventorsvm.html

●例２→自分好みの新たなブロックをJavaで自作する。

JSONのデコード用の新たなブロックをJavaで作った例です。

A JSON Decoding Extension for App Inventor (1)

https://sparse-dense.blogspot.com/2019/01/a-json-decoding-extension-for-app.html

●例３→JavaよりもJavaScriptを使いたいのならば。（基本編）

Make MIT APP Inventor more powerful with JavaScript

https://sparse-dense.blogspot.com/2019/10/extending-mit-app-inventor-with.html

●例４→もっとJavaScriptを活用する。（学習済みモデルの利用）

MIT App InventorとGoogle Teachable Machine2を連携させた例です。

https://sparse-dense.blogspot.com/2019/11/mit-app-inventorgoogle-teachable.html

●例５→Eddystone信号でmicro:bitと連携する。

Cooperation between micro:bit and MIT App Inventor with Eddystone signals (No.1)

https://sparse-dense.blogspot.com/2018/05/cooperation-of-microbit-and-mit-app.html

利尻岳（北海道）五月の風景

 　最近になって、北海道にも新型コロナウィルスに関する緊急事態宣言が発令されました。現地へ出かけることはできませんが、利尻町のホームページで公開されているライブカメラで利尻岳（利尻富士とも呼ばれる日本百名山の一つで標高1,721m）の様子を楽しむことができます。最近そこで閲覧した、残雪の美しい山の風景を以下に載せたいと思います。

●利尻町ホームページ

http://www.town.rishiri.hokkaido.jp/rishiri/1.htm

（注）上記写真掲載は、上記の「利尻町ホームページへのリンクを希望される方へ」の利用ガイドラインに沿って行っています。

トランザクションデータのグループ化（JavaとPython）

    【what is this】トランザクションデータなど、複数のカラム（キー）からなるデータを、特定のいくつかのカラムについて、階層的にグループ化したい場合があります。JavaとPythonを使って、簡単な例で試してみます。

　本記事で扱う小さなデータ（csvファイル）とソースコード（JavaとNotebook形式Python）はこちらにありますので、よろしければお使い下さい。

■例題：トランザクションデータ（通貨取引）のグループ化
　何をしたいのかを、図１で説明します。図１(a)は、参考資料[1]のcsvデータを若干編集したものです。先頭行は、３つのカラム名（City, Currency, Value）を示しています。２行目以降のトランザクションを集約して、右側の(b)に示すように、取引所（City）でグループ化し、さらに通貨（Currency）毎の取引額（Value）の平均値を求めたい。この処理は、初歩的なプログラミングでも可能ではありますが、恐らく、込み入ったものになるでしょう。ここでは、分かりやすく、効率的なプログラムにしたいのです。

■JavaのStream、groupingByの利用
　図２に示したJavaプログラムは、StreamとCollectionのチュートリアルである参考資料[1]を参考にしています。まず、１〜2行目で上記のcsvデータを読み込み、３行目でトランザクションを３つのカラム対応のデータに分割しますが、データの先頭行は不要なので4行目のfilterで削除します。５行目では、各トランザクションに対するオブジェクトを生成しています。そのクラスの定義は(b)にあります。このオブジェクトのプロパティを利用して、６〜７行目で、Cityについてグループ化し、さらにCurrencyについて纏めてそれらの平均値を得ています。ストリームに対するgroupingByが２重に適用されているところがポイントです。ここで、例えば、「Tranz::getCity」は、トランザクションオブジェクトに対して、一斉にクラスTranzのメソッドを適用する（Cityデータを得る）ことを意味します。８〜11行目は結果の出力表示です。

　１〜7行目までの、２重のグループ化では、if文もforループ文も使われておらず、処理の流れを把握しやすいのが魅力です。実行結果は、図１(b)のようになります。

■ Pythonのpandas、groupbyの利用

　次に同じことを、資料[2]を参考にしてPythonでやってみます。グルーピングの考え方はJavaの場合と同じですが、Pythonでの記述量は、図２(a)のように大幅に少なくできます。実質１行（４〜５行目に渡る）で、右側の(b)の実行結果が得られます！素晴らしいですね。PythonのモジュールPandasを使っており、そのなかのgroupbyが効果的に働いています。そして、Javaの場合に切り捨てた先頭行のカラム名（City, Currency, Value）が、自動的に内部で生成されるオブジェクトに対応しています。

　このように、PythonのPandasは効率的プログラミングに貢献しています。しかしながら、これで全面的にPythonの勝利ということではないでしょう。Javaの場合は、明示的に生成したオブジェクトと一連の処理がstreamとして分かりやすいという捨てがたい魅力があります。また、JavaのStream（とそしてラムダ式）は、マルチコアマシン上での並列実行性能を高めるためにあるとも言われますので、大規模データ処理の場合の性能比較も楽しみになります。

[参考資料]

[1] Raoul-Gabriel Urma, "Java SE8ストリームを使用したデータ処理(パート1 & パート2)", Oracle.com/JavaMagazine, March/April, 2014.

[2] Soner Yıldırım, "3 Python Pandas Tricks for Efficient Data Analysis",

https://towardsdatascience.com/3-python-pandas-tricks-for-efficient-data-analysis-6324d013ef39

状態価値関数（ベルマン方程式に基づく）に親しむ（その２）

   【what is this】前回の記事では、ベルマン方程式に基づく「状態価値関数」とは何かをビジュアルに表示して理解しました。そこでは、動き（行動）を決めるための特定の「行動ポリシー」についての状態価値関数を扱ったのですが、今回は、この状態価値関数の値をどの状態においても最大にする（最も優れた）行動ポリシーの自動探索です。

■２次元Grid Worldに対する状態価値関数（復習）
　図１左側の２次元の指定マスから開始して、ひとマスづつ進めて、右下隅のゴールをめざします。移動方向は上下左右ですが、それぞれ選択確率があります。ここでは、右と下へそれぞれ確率0.5で選択され、それ以外は確率0とします。このような行動ポリシーをπRDとします。移動する毎に報酬（-1という負値）が付与されます。各マスからゴールをめざして得られる報酬の合計見込み額が状態価値関数の値です。これは、統計学での「期待値」であり、これが大きいほど少ないステップでゴールします。図1右側の数値は、各マスの状態価値関数値です。ゴールGに比較的近いマスでの値の絶対値は、そこからゴールに至る移動回数と一致しています。

　ここで、中央に「落とし穴P」があることにご注意下さい。移動先がこのPとなる場合は、ただちに、ワープ確率αで左上隅に戻り、確率(1-α)でゴールへ達します。α=0.4の場合は、Pに達すると確率0.6でゴールしてしまうわけですから、Pの回りでの期待値は少し高まるでしょう。実際、例えば、Pの上と左は-6.3となっており、Pが存在しなかった場合の-7.0よりも大きくなっています。

■最適な行動ポリシーを自動的に探索する

　上記では、特定の行動ポリシーπRDについての状態価値関数を示しました。次にやりたいことは、このπRDよりも優れた（大きい状態価値関数値を与える）行動ポリシーを見つけることです。詳細は、参考文献[1]などをご覧いただきたいのですが、その具体的な方法はいくつかあります。ここでは、「ポリシー反復法」と呼ばれるものを使いました。この方法は、簡単に言えば、囲碁の場合でもそうかと思いますが、「一手だけ先読みして最適そうな手をとる」の繰り返しになります。

　ところで、上記の例題の場合、「最適な行動ポリシーπ*」とは具体的にどんなものでしょうか。それは、上記πRDでの確率は0だった左や上方向への行動も含むことになります。そして、「最適」の言葉どおり、各状態（本例ではマス）ごとに、いずれかの方向への移動の確率を１に設定することになります。具体例を図２でご覧下さい。

　落とし穴にP関するワープ確率αの値などは、図１と同じです。図２左側のマスの中の太矢印は、確率１となった行動（移動方向）を示しています。Pの左側と上側の矢印は、積極的に落とし穴Pへ向かっています。これは最適行動ポリシーとして納得できるでしょう。図２右側は、その場合の状態価値関数ですが、こちらも同様に納得できます。

　さらに図３をご覧ください。ワープ確率α=0.1の場合は、もっと高い確率（=0.9）で素早くゴールに達することができるため、Pの広範な周辺のセルからの移動がPに向かっています。これが最適ポリシーになることも理解できます。

　今回の記事はこれでお終いですが、最後に、もっと大きなグリッドで、この技術の素晴らしさを楽しみましょう！美しい図４の結果をご覧下さい。

■まとめ
　分かってしまえば、それほど難しくありません。しかし、「状態の価値」という捕まえ難い概念を、コンピュータで扱えるようにしたこの理論と手法は素晴らしいです。これを最初に編み出した先人に敬意を表したい気持ちになります。さらに、一歩づつ先へ進みたいと思います。また、参考文献[1]の丁寧で精緻な叙述は、学習意欲を維持するのに非常に大きく貢献しています。本記事は、これ基づいて（説明文や図は小生の自作ですが）書きました。

[参考文献]

[1] 中井悦司：ITエンジニアのための強化学習理論入門、技術評論社、2020年７月

状態価値関数（ベルマン方程式に基づく）に親しむ（その１）

  【what is this】現代AI技術において、強化学習（Reinforcement Learning）は重要です。これをご存じ無い方、または、（実は私もこれに該当しますが）少しは知っているがもっと明確にしたい方のために、ベルマン方程式に基づく「状態価値関数」とは何かをビジュアルに観察して、親しみを持ちましょう。さらに先をめざす手掛かりとして。

■ベルマン方程式にもとづく状態価値関数
　詳細を把握するには、例えば中井悦司著の強化学習に関する書籍[1]を読んでいただく必要がありますが、ここでは、状態価値関数の一面に親しむことにします。実際、以下の内容は、この書籍の第２章（pp.45-100）を学んで得られる成果（結論）なのです。

■例題：２次元Grid Worldに対する状態価値関数
　強化学習の定番例題のひとつに、２次元GridWorldがあります。そのバリエーションは多様ですが、ここでは図１のような設定にします。すなわち、２次元の特定のマスからひとマスづつ進めて、右下隅のゴールをめざします。ただし、進行方向は右か下かに限定され、それぞれ1/2の確率で選択されます。どのマスから開始すれば少ない移動回数でゴールできるでしょうか。（この例ではそれは自明かも知れませんが、一般的な解決手法を得たいのです。）

　ここで「状態価値関数」とは、各マスからゴールへ到達するという観点から、そのマスの価値（有利性）を示すものと言えます。統計の言葉で言えば「期待値」です。本例では、移動する毎に報酬（-1という負値）を与えることにします。従って、報酬の合計が大きいほど、少ない回数でゴールできます。この報酬と上記の移動確率などから「ベルマン方程式」というのが導出され、その解が「状態価値関数」に相当します。

　詳細理論はおいておき、本例に対する状態価値関数をみてみます。図１(a)では、予想どおり、左上隅から右下隅方向へ向かって、「価値」が高くなっています。マスの上の数値が状態価値関数の値であり、それが大きいほど価値が高いです。グラフでは、赤が濃いほど大きな数値で、青が濃いほど小さな数値を示しています。

　一方、図１(b)では、中央に「落とし穴」を設定しました。移動先がこの穴Pとなる場合は、直ちに、左上隅へ戻るか（確率=0.9で）、右下隅ゴールへ（確率=0.1で）移動してしまいます。したがって、これは確率的に不都合な落とし穴です。実際、この落とし穴の上、左、左上方向のマスの価値は低くなっています。図１(c)は、これとは逆に好都合の落とし穴です。落とし穴の上、左のマスの価値は高くなっており、この場合も納得できる結果が得られています。

　さらに、以下の図２は、グリッドを19x19に拡大した場合です。図１に比べて、より鮮明な結果をみることができます。

■まとめ
　ここでは、マスの右と下へある確率で移動する、という特定の行動ポリシーのもとで状態価値関数をみました。別の行動ポリシー（例えば、右と下へ移動する確率が均等でなかったり、斜め方向にも移動するなど）の場合は、当然、この状態価値関数は変わります。また、どのマスから開始しても、いつもこの関数値が一番大きくなる行動ポリシーを見つけることや、大規模なworldに対する状態価値関数の効率的な計算法も大きなテーマになります。

[参考文献]

[1] 中井悦司：ITエンジニアのための強化学習理論入門、技術評論社、2020年７月

小学校で習う「平均」されど「平均」（揺れる平均値）

 【what is this】前回の記事の簡略化バンディット問題では、各ボタンBnが発する乱数（符号付き実数）は、平均Mnで標準偏差１の正規分布としました。このMnは、１ゲーム（１エピソード）中は変わりませんが、操作者には知らせていません。今回は、このMnが（雑音が入るように）ある程度変動する場合を扱います。この条件下で、ある与えられた回数だけ、いずれかのボタンを押して、得られる合計点をできるだけ高くしたい、という問題です。

■設定平均値が変動する場合の正規分布乱数
　ボタンnが発する乱数は、前回と同様に、平均Mnで標準偏差１の正規分布とします。前回は、このMnは、１ゲーム（１エピソード）中は変わりませんでしたが、今回は、変動します。すなわち、今回はゲーム中に、Mnに、平均0で標準偏差sd（例えば、sd = 0.01）の正規分布の雑音が加算されます。現実の世界では、こういうケースの方が一般的です。
　図１は、あるボタンを1万回押した場合に発生した乱数の分布例です。図１(a)は前回のとおり（設定）平均値が固定の場合、図１(b)は変動する場合であり、平均には、平均0で標準偏差0.01という正規分布乱数が毎回加算されていきます。図のとおり、両者には一定の差異が生じます。

■設定平均値が変動する場合の解法の戦略
　どのボタンを選ぶべきかという行動のポリシーは、前回と同じε-greedyです（最適値としてε = 0.1を設定しています）。その「活用」フェーズでは、その時点で得られている各ボタンの乱数情報から、推定平均が最も高いボタンを選択してきました。しかし、上記図１(b)のように、毎回設定平均値が変動する場合は、必ずしもそれがうまく働かないようです。詳細は参考文献[1]を参照戴きたいのですが、「新しいパラメータαを用いた、推定平均値のような新たな量」を定義し、それが最大のボタンを選択していく戦略があります。それを「非定常状態対応戦略」としておきます。

　図２にはその戦略による評価結果を示してあります。詳細は図の右側の説明をご覧下さい。この新しい戦略で、前回の「推定平均値を求める戦略」よりも良い結果が得られています。

[参考文献]

[1] 中井悦司：ITエンジニアのための強化学習理論入門、技術評論社、2020年７月

小学校で習う「平均」されど「平均」（基本編）

【what is this】日常生活にも多く出現する「平均」は、小学校高学年の算数で習います。それは、AIの重要分野である強化学習（Reinforcement Learning）においても不可欠です。実際、強化学習の書籍[1][2]でもそのように扱われています。そこで、本記事では書籍[1]を参考にさせていただき、改めて「平均」をプログラミングしながら再考したいと思います。
（→続編はこちらです）

■簡略化した多腕バンディット問題
　ここでは、簡略化したバンディット問題を扱います。具体的には、６個のボタンがあり、それを押すと、それぞれ乱数で得点が得られます。各ボタンBnが発する乱数（符号付き実数）は、平均Mnで標準偏差１の正規分布になっています。ただし、操作者は、それらの平均値Mnを知りません。この条件下で、ある与えられた回数だけ、いずれかのボタンを押して、それらからの合計点をできるだけ高くしたい、という問題です。
　図１には、合計で2,000回、全くランダムにボタンを選んで押した場合の乱数の分布を一例として示しました。（どのボタンでも、設定平均値と実際に発生した乱数の平均値はぼぼ合致しています。）

■ε-greedyポリシーに基づくボタンの選択
　この問題に対する戦略として、「ε-greedyポリシー」があります。与えられた回数の範囲で、各ボタンの平均値Mnを推定しながら進めます。とにかく、ボタンが選択される毎に、そのボタンの乱数の推定平均値は正確な値に近づくはずです。しかし、いつまでも広く異なるボタンを選択し続けると、（回数の制約上）高い推定平均値のボタンを選択する機会が減り、総合得点が高くなりません。逆に、ある時点での推定平均値の高いボタンを固定的に押し続けると、他により好ましいボタンがあってもそれを活用できません。そのバランスを取るために、パラメータεを導入します。ボタン選択にあたって、乱数p（0.0 < p <1.0）を発生させて、

(1) p < εならば、ランダムにボタンを選択する。
(2) p >= εならば、この時点での推定平均値が最大のボタンを選択する。

　この戦略で、ε = 1.0, 0.5, 0.1について、それぞれ200回（=１エピソード）ボタンを選択した場合の総得点の比較を、図２に示します。乱数を使っているため、常にこのとおりとはなりませんが、多くの場合、図２のように、ε = 0.1の場合が最適になります。すなわち、その時点の推定平均値が最大のボタンを選ぶことを基本とするが、10回に１回程度は、ランダムにボタンを選ぶのが最適だということです。

■グリッドサーチで、パラメータε の最適値を求める
　上に述べた「ε = 0.1が最適」というのは、各ボタンの元々の設定平均値が変わった場合でも成り立つでしょうか。それを確認するため、ε = 0.0〜1.0の範囲の11刻みで、設定平均値を変えてそれぞれ1,000エピソード（=1,000 x 200回）実行させた（グリッドサーチ）結果を図３に示します。ここでは、中央値を「箱ひげ図」で比較しましたが、統計学的に予想どおりの結果となりました。

　この図によれば、ε = 0.0、すなわち、常にその時点での推定平均値が最大のボタンを選択するのもかなり良い。しかし、とくに初期段階では最大値を与えるボタンが変動しやすいので、その最大値はあまりあてにならない。そのため、一定の間隔で、それをご破算にして、あらたに最大値を求めた方がよいということでしょう。

■ボタンの選択状況をさらに詳しく分析する

　ここまでで、本記事は一応終わりなのですが、上記のパラメータε= 1.0, 0.5, 0.1の場合それぞれで、どのようにボタンが選択されたのかを、さらに詳しく確認したいと思います。以下は、図２の実行時の分析です。プログラミングの観点からも、下図のような作図は有用と考えました。

　ε= 1.0の場合は、推定平均値のより高いボタンがないかを探索しすぎたため、好ましいボタン１を選択（活用）する機会を失ったと言える。これに対して、ε= 0.1の場合は、開始直後は他のボタンの推定平均値の方が高かったが、途中からボタン１の方が有利になり、ほぼその選択を維持できたのが勝因と言えます。

   

■感想
　本記事は、ほとんど「平均値を推定する」という話題につきますが、状況を徹底的に調べることで理解が深まると感じました。その際のプログラミングは、言語はどれでも良いのですが、今回は、PythonのListやDictionary、それとPandasのplot機能を有効に活用できたと思います。

[参考文献]

[1] 中井悦司：ITエンジニアのための強化学習理論入門、技術評論社、2020年７月
[2] 曽我部東馬：強化学習アルゴリズム入門、オーム社、2019年５月