이번 세미나는 그리드월드를 정책 이터레이션으로 구현하는 것(p76 ~ p92)이 목표입니다.

코드의 중요한 사항을 살펴보고 개선할 점들을 도출해 보겠습니다. 책의 예제는 이름 그대로 예제로 작성하는 것이기에 문제가 많을 수 밖에 없습니다. 비난하려는 의도가 전혀 없음을 먼저 주지하고 진행하시면 좋겠습니다.

p76 ~ p78

__init__

모든 상태의 가치 값은 0으로 초기화하고, 각 상태에서 결정할 수 있는 액션들은 같은 확률로 초기화합니다. 4가지 액션이 가능하니 25%의 확률로.
벨만 기대 방정식을 구현하기 위해서는 모든 상태들에 대한 이전 가치 값(value_table)이 관리되어야 합니다. 이번 구현에서 가장 중요한 부분이라고 생각합니다.
마침 상태는 그리드월드에 의해 정해집니다. 정책 이터레이션의 책임이 아닙니다.
value_table과 policy_table을 초기화하는 방법이 맘에 들지 않습니다. 좀 더 간단하고 직관적인 방법으로 작성합니다.

policy_evaluation

함수 이름을 동사가 먼저 나오도록 바꿉니다. evaluate_policy
[2, 2]가 마침 상태인지를 알 수 없습니다. 그리드월드에서 알 수 있습니다. 이것을 알 책임이 없습니다. [2 ,2]인지를 체크하고 그 밑에서는 2, 2 값을 사용하지 않고 state를 통해 구하고 있네요.
next_value_table의 초기화 방식도 바꿉니다.
p69의 수식 3.5를 구현합니다. p77. 구현된 소스코드와 비교해 봅니다.

policy_improvement

policy_evaluation에서 지적된 사항들과 같은 부분들을 고칩니다.
한 상태에서 가능한 액션들에 대해 개별 액션의 큐함수 값을 구합니다(p73의 수식 3.9).
상태의 정책을 갱신하기 위해 수식 3.10을 구현합니다. 탐욕 정책을 따를 것이니, 가장 큰 값을 가지는 액션의 확률을 100으로 나머지는 0으로 합니다. 같은 값을 가질 수 있음을 고려해서 구현해야 합니다.
이 값이 어떤 상태에서 특정 액션을 선택할 확률이 됩니다.
탐욕정책을 취합니다. 같은 값이 즉구현된 소스코드와 비교해 봅니다.
value, max_index, result의 초기화 부분과 그 뒤의 정책을 결정하는 부분들의 소스 코드가 정신없어 보입니다.

get_action

처음 볼 때는 꽤 그럴싸한 방법으로 보입니다. 정당한 것인지는 좀 더 살펴봐야할 것 같습니다.
return이 특별한 조건에서만 일어나도록 코딩하는 방법은 좋지 않습니다.

get_policy

이전에 지적된 사항들과 같은 부분들을 고칩니다.

추후 위에서 지적한 사항들과 다음과 같은 내용들을 반영해서 소스 코드를 재 구현한 후 공유하도록 하겠습니다.

그리드월드(GridWorld)는 그리드(Grid)로 구성됩니다 – 5행(rows) 5열(cols) 25개의 그리드가 있다. 모든 그리드를 사용해서 뭘 하지는 않는다.

그리드월드에는 장애물이 놓여지는 그리드(obstacle_grids)와 목표가 놓여지는 그리드(goal_grid)가 있습니다.

그리드월드는 에이전트를 갖습니다.

에이전트는 시작 위치(agent_start_grid)에 놓여집니다. 에이전트는 정책을 갱신할 수 있는 방법을 갖고 있습니다. 이번 구현에서는 정책 이터레이션(PolicyIteration)을 사용합니다.

그리드는 행(row)과 열(col)을 갖습니다. 예) 첫 번째 그리드는 row=1, col=1

GraphicDisplay는 UI 구현에 충실하고, GridWorld의 개념과 관련된 것들을 GridWorld에서 다루도록 합니다. GraphicDisplay는 GridWorld에 대해서 알아야 합니다. 이번 구현에서는 에이전트의 역할은 거의 없습니다. GridWorld는 정책을 평가하고 발전시키기만 하면 되기 때문에 에이전트 개념을 사용할 필요는 없습니다.

메인은 별도로 분리한다(main.py).

현재 구현에는 다음과 같은 문제가 있다.