mjxprotoの変更したい箇所リスト

[habara-k]

概要

mjxprotoの変更したい箇所をまとめておいて、頃合いを見て一括変更する

変更希望箇所

• Event.NoWinnerTypeを加えたい

理由: Eventを見るだけで、ただの流局なのか九種九牌なのかがわかるようにしたい

[habara-k]

• 九種九牌の表記ゆれ

  • kyusyu
  • kyuusyu
  • kyushu
  • kyuushu
  • nine tiles

等の表記があり、統一したい

[sotetsuk]

何がpublicで何がprivateなのかをより明確にしたいかもしれない。 ポーカーの論文では、public observation や private observation のような単語も使って整理してたので、参考になるかもしれない。 （河は public observationで、closed handは private observation ）

[sotetsuk]

PettingZooに合わせると、Stateに次のプレイヤーが誰かの情報がほしいかもしれない。 ただこれは天鳳との兼ね合いを考えると微妙かもしれない。。。

[sotetsuk]

現在のハンドが入ってないが、いれるかどうか。。。

[sotetsuk]

TerminalもEventの中に入れたほうが自然か？

[sotetsuk]

PrivateInfo はミスリーディングか。（InfoがImperfect Information gameのInfoと同じように見える）

[sotetsuk]

見直して思うのは、どの情報が更新されて、どの情報がfixedなのかがわかりにくい。

• EventHistoryにだけ動く情報を全て集約した方がいいかもしれない（？）

[sotetsuk]

Draft => #694

方針

• キッチリ定義が必要なところをなるべく減らして、重複している情報などは utils へ突っ込む。utils なしで、過不足ない情報がしっかり定義されている、としたい。
• 名前も定義がわかりやすいようにしたい（日本人以外でもわかるのがベストだが、無理なら最低日本人はわかる。いつ更新されているのかわかる。など）

TODO

• [x] Wind, RelativePosを消す（protoの定義をfixするため、絶対必要でないものは消す）
• [ ] NoWinnerType を EventType と統合へ（Terminalを見に行かなくて済むように。ActionとEventの整合性を取りやすいように）
• [x] AbsolutePos も消す（結局、size = 4 のリストを配列を多様しているので）
• [ ] NoWinnerType => RoundEndType
  • [ ] 並び替え
  • [ ] Ron, Tsumo を追加
• [x] ActionType
  • [x] 順番の並び替え（EventTypeとの整合性も取る）
  • [x] Kanのリネーム（wikiに揃える）
  • [x] 九種を ABORTIVE_DRAW_NINE_TERMINALS へ
  • [x] DISCARD を DISCARD と TSUMOGIRI に変える（Eventとの整合性）
• [ ] EventType
  • [x] 順番を並び替え（ActionTypeと揃える）
  • [x] DISCARD_FROM_HAND => DISCARD, DISCARD_DRAWN_TILE => TSUMOGIRI に変える
  • [x] Kan のリネーム
  • [ ] 流局のタイプを EventType に追加する（Terminal を見に行きたくない）
  • [ ] 終局の EventType を追加する（Terminal を Utils 以下に隠すので、 Terminal なしでダブロンを判断するため）
• [x] Action
  • [x] DISCARD を DISCARD と TSUMOGIRI に変える
  • [ ] optional
• [ ] Event
  • [ ] optional
  • [ ] 九種九牌で who が必要
  • [ ] ROUND_END を追加
    • [ ] Ron , Tsumo を RoundEndType へマージ。（天鳳のフォーマットへ近く、ダブロンと三家和了の動作の違いが気になる）
    • [ ] shown_hands の追加
    • [ ] ura_dora_indicators の追加
• [x] Score
  • [x] ten => tens
• [ ] TenpaiHand => Hand
  • [ ] rename
  • [ ] opensを加える
• [ ] EventHistory => PublicObservation
  • [x] rename
  • [x] init_score の追加
  • [x] init_dora_indicator の追加
  • [x] events => event_history
  • [ ] Utils の追加
    • [ ] curr_score の追加
    • [x] curr_dora_indicators の追加
    • [ ] river の追加
    • [ ] round_terminal の追加
• [x] PrivateInfo => PrivateObservation
  • [x] draws => draw_history
  • [ ] utils の追加
    • [ ] curr_hand の追加
• [ ] Observation
  • [x] init_socre を public_observation へ移す
  • [x] doras を次の二箇所へ分ける
  • [x] init_dora_indicator in public_observation
  • [x] curr_dora_indicators in public_observation.utils
  • [x] event_history => public_observation
  • [x] priate_info => private_observation
  • [ ] possible_actions => private_observation.utils.legal_actions
• [ ] Win（utils以下に移される）
  • [ ] closed_tiles と opens を hand にまとめる
• [ ] NoWinner => Draw
  • [ ] TenpaiHand tenpais => Hand tenpai_hands
  • [ ] NoWInnerType => EventType
• [ ] Terminal => RoundTerminal
  • [ ] rename
  • [ ] NoWinner no_winner => Draw draw
• [ ] State
  • [x] player_ids を public_observation.utils へ移す
  • [x] game_id を public_observation.utils へ追加
  • [x] game_seed を hidden_state.utils へ追加
  • [x] wall を hidden_state へ移動
  • [x] ura_doras を hidden_state.utils へ移動
  • [ ] terminal => public_observation.utils.round_terminal
  • [x] HiddenState hidden_state を追加
  • [x] wall を hidden_state へ追加
  • [x] hidden_state.utils を作成
    • [x] curr_ura_dora_indicators を追加
  • [x] public_observation を追加
  • [x] private_infos => private_observations

[sotetsuk]

• 他にも、 No も加えた History が合ったほうがいいような気もするし
• 次が誰のターンか、という情報も合ったほうがいいような気もする
• legal_actions も全てのdecision pointであれば便利
• utils => optional ??

[habara-k]

他にも、 No も加えた History が合ったほうがいいような気もするし

天鳳のlogにはNoがない => mjxproto形式で NoをHistoryには加えにくい

（教師あり学習では、例えばチーをできた状況で他家のポンが入ったとき、チーをせずNoを選んだ扱いにしているが、これは学習においてそこまで影響がないという仮定の元での妥協案である。厳密なプロトコルを作る今回の場合、ここを妥協しない方が良さそうな気がする）

[habara-k]

legal_actions も全てのdecision pointであれば便利

これはObservationUtils.legal_actions で達成可能という認識で良いでしょうか？

[sotetsuk]

他にも、 No も加えた History が合ったほうがいいような気もするし

天鳳のlogにはNoがない => mjxproto形式で NoをHistoryには加えにくい

（教師あり学習では、例えばチーをできた状況で他家のポンが入ったとき、チーをせずNoを選んだ扱いにしているが、これは学習においてそこまで影響がないという仮定の元での妥協案である。厳密なプロトコルを作る今回の場合、ここを妥協しない方が良さそうな気がする）

まあもし加えるとしたら、今の event_history は No なしのまま据え置いて、 別に utils 以下に No もある完璧なhistoryも別で保持するという形になるかなあという感じですね。

[sotetsuk]

legal_actions も全てのdecision pointであれば便利

これはObservationUtils.legal_actions で達成可能という認識で良いでしょうか？

強化学習のときには

• もし学習データを各 Observation のjsonデータから作るなら、 legal_actions が入っている現状で問題ないです（通常の強化学習）
• もし学習データを State のjsonデータから作るなら legal_action_history のような系列を保持する必要があるかと思います（通常の強化学習から、教師あり学習に寄せたイメージ。データサイズがかなり小さくなるはず。オフライン強化学習という分野も流行りだし、実用性は高い）

教師あり学習のときには、後者のパターンなので、同じくヒストリがないとダメだと思います。

[habara-k]

Observation.ObservationUtils 内にlegal_actionが存在するのはロジック的に大丈夫なのか？

Observationはあるplayerから観測したStateであるので、例えば他家が直前の捨牌をポンできるかどうかはわからない方が良い

legal_actionを付け加えるとするなら、State.legal_actionが良い気がする。 => 次が誰のターンか、という情報も合ったほうがいいような気もする も解決可能

[habara-k]

代替案

• legal_actionをwhoごとに分けて、それぞれをState.PrivateObservation.legal_actionに格納する

[sotetsuk]

代替案

• legal_actionをwhoごとに分けて、それぞれをState.PrivateObservation.legal_actionに格納する

僕の頭の中のイメージはこれでしたね。現状の実装とズレがありますね。ありがとうございます。 現状の legal_actions は private_observation か private_observation.utils の下に移されるべきですね。

[habara-k]

legal_actions_historyを例えば

LegalActions
|- repeated Action actions

PrivateObservation
|- repeated LegalActions legal_actions_history

のようにもつ場合、private_observation.legal_actions_historyとpublic_observation.event_historyの対応関係をとるのが難しそう。

（private_observation.draw_historyはpublic_observation.event_historyの内、who=自分, type=drawのものと順番に対応するので簡単に対応が取れるが、legal_actionsは自明な対応が取れなさそう）

[habara-k]

特徴量生成の高速化のため、repeated bool PublicObservation.under_riichi を加えてもいいかもしれない。

[sotetsuk]

PlayerIdx は本当に必要なのかも謎。結局、色んな場所で暗黙的にユーザをリストで持ち、 0 = 起家 を仮定している。（ Score など） ただ、あったほうがわかりやすいのも事実ではある。

[sotetsuk]

先日のディスカッションメモ

• No や実現しなかった Chi のような行動履歴を含む、完璧な行動履歴を用意するか否かは、自己対戦のデータをどのように保存するかにも依存する。
• 次の手番が誰かという情報も、上記の完璧な行動履歴を保存するかに依存する。
• legal_actions の履歴を持つかも、上記の意思決定に依存する

[sotetsuk]

チェック項目

• [x] utils なしで過不足ない情報がそろっているか

[sotetsuk]

あとの懸念はEventとActionをマージするか否かくらいか。これもやはり完璧な行動履歴を用意するかに依存している気がする。

[sotetsuk]

TakeAction しかメソッドを用意してないが、現状だと Observation は意思決定が必要な状況でしか生成されないので、終局時にその情報が渡されない。これはRLをする上で問題になるかもしれない。ダミーの行動を用意した方がよいか。

[sotetsuk]

player_idはシミュレータ側で設定しているが、いいのか？ エージェント側がもっているべきとう説もある

[sotetsuk]

mjx.proto 変更による影響

• mjconvert のテスト資材でコミットされているのは mjlog と mjscore 形式だけなので、影響はないはず
• C++の mjx のテスト資材は tests/resources/json 以下に配置されているので、これを更新する必要がある

更新手順

1. mjx.proto と必要な修正を更新

2. まず、python側が動くことを確認

もし mjconvert 以下で venv がなければ $ make venv してからアクティベートした方がよい。

$ cd mjconvert
$ make clean && make install
$ make pytest
$ make test-cli  // これはテストとしてちゃんと機能しているのか怪しい

現実には、 make clean && make install と make pytest を繰り返しながらコードを修正していく。 IDEやVSCodeでprotoの変更による AttributeError は検知してくれる場合が多い。 最後に make formats で整える。

3. C++側のテスト資材を作り直してコミット

2.でコマンドを実行したのと同じ、 mjconvert ディレクトリで

$ mjconvert ../tests/resources/mjlog ../tests/resources/json --to-mjxproto --verbose
$ git add ../tests/resources/json
$ git commit -m "update test resources"

4. C++側のテストを実行

CLionで変更とテストをしていく（あるいは make） cmake-build-debug も頻繁に消す必要がありそう。

修正例

https://github.com/mjx-project/mjx/pull/702

• protoファイルの修正: https://github.com/mjx-project/mjx/pull/702/commits/5d0cd624067d25a5b843f2d69f867c41a3026cbb
• Pythonファイル（mjconvert）の修正 https://github.com/mjx-project/mjx/pull/702/commits/e19b310797905a779e81e61e74c1c2ddff787a2c
• テスト資材の更新 https://github.com/mjx-project/mjx/pull/702/commits/57af4df32dc5abc9fc44a306029f6404177e34e6
• C++ファイルの修正 https://github.com/mjx-project/mjx/pull/702/commits/20e9dbf9993db0c7f7cd1731f7ef21107a8c0506

[sotetsuk]

RoundTerminal は State としては確かに utils の下に突っ込んでもいいけど、 Observation としては utils の上に置いておかないとダメかもしれない。

[sotetsuk]

RoundTerminal をどうするか？

1. [そのまま] （スリムにして） utils の上へ動かす
2. Event の Win に from_who や Hand を加えて、 Tenpai のような EventType も追加して対処する
3. [2.よりは現状との差分が少ないか] Event に新しく RoundTerminal typeを加えて utils の情報を terminal_info のようなattributeへ移す
   • 誰が、どの手で
4. [天鳳] EventTypeとして AGARIE, RYUUKYOKU があり、それぞれ全員分の上がりや流局情報を保持

[sotetsuk]

protobufは最新版からoptionalが使える

optionalが使えるなら、例えば Action も本当は discard や open は optional が正しい

[habara-k]

裏ドラはHiddenStateUtils 以下に入る予定だが、立直した人が上がった場合、裏ドラの情報を何かしらの方法でpublicにするべきか？