태그 보관물: python

Alpha-Beta Pruning으로 Minimax 탐색시간 개선

댓글 남기기

Minimax Algorithm과 간단한 예제 포스팅에서 사용했던 예제에서 main()함수에 있는 total_coins 변수의 값을 12에서 32이로 증가시켜서 실행해 보면 컴퓨터가 답을 내는 시간이 기하 급수적으로 늘어나서 첫 대답을 탐색하는데 대략 30초 정도 시간이 걸리는 것을 볼 수 있다(Macbook Pro M5 기준).

def main():
    total_coins = 32 # 원래는 12임.
    ...

이는 각 노드들의 선택가능한 조건이 3개씩이어서 32개의 코인을 가정하는 경우 이론상 대략 1000조가지가 넘는 노드들을 탐색해야 하기 때문이다.

Pruning(가지치기)

하지만, 실제로는 모든 노드들을 탐색해야 하는 것은 아니다. 개중에는 어차피 탐색해 들어가 봤자 선택되지 않을 값을 가진 것들이 있기 때문에 이러한 것들을 미리 알 수만 있다면 탐색 할 필요가 없는 경로들에 대해 탐색을 수행하지 않음으로써 소요되는 시간을 아끼고 효율적인 탐색을 수행할 수 있다. 이러한 동작을 “가지치기”라고 하는데, alpha와 beta라는 두개의 경계값을 유지하는 것으로 이루어진다.

  • α(alpha): 현재까지 Max(컴퓨터)가 확보한 가장 높은 점수
  • β(beta): 현재까지 Min(사용자)가 확보한 가장 낮은 점수

탐색 도중에 α >= β가 되는 순간이 있다면, 이러한 경로는 선택될 리가 없다고 가정하고 탐색을 중단한다.

구현 예제

다음의 코드는 “변형 nim game” 예제에 Alpha-Beta purining을 적용한 것이다.

실행결과 및 결론

이 프로그램을 실행하고 컴퓨터의 턴으로 게임을 시작하면 기존에 30초 가량 걸리던 탐색시간이 2초 정도로 줄어드는 것을 확인할 수 있다.

아마도 비슷한 글:

  1. Minimax Algorithm과 간단한 예제
  2. Heap tree 만들기
  3. OpenVINO Object Detection Model의 전처리와 후처리를 간단하게
  4. Jinja2의 UnicodeDecodeError

Minimax Algorithm과 간단한 예제

댓글 남기기

Minimax algorithm은 체스나 장기, 틱택토 혹은 오목 처럼 두 명의 플레이어가 번갈아 가면서 턴을 주고받는 유한 제로섬 게임(Finite zero-sum game)에서 최적의 선택을 내리기 위해 사용 할 수 있는 결정 트리 탐색 알고 리즘이다. 다시말해, 내가 얻는 이득이 상대의 손실이 되고, 내가 보는 손실이 상대의 이득이 되는 구조에서, “상대방은 항상 자신에게 유리한 선택을 하고 나에게는 불리한 선택을 한다”는 가정하에 자기 자신의 손실을 최소화(minimize)하고 이득을 최대화(maximize)하는 전략을 찾는 것이다.

이 포스팅에서는 minimax algorithm의 개념을 이해하고 간단한 게임에 적용시켜 최적의 해법을 찾아내는 과정을 확인해 본다.

Max Player와 Min Player

Minimax 알고리즘에서는 두 플레이어를 각각 Max와 Min으로 정의한다.

  • Max Player (컴퓨터): 자신의 점수를 maximize하려는 플레이어.
  • Min Player (상대방): Max의 점수를 minimize하려는 플레이어.

이 그림은 Max와 Min 두 플레이어가 서로 턴을 바꿔가며 결정하는 예제를 단순화 해서 트리로 그린 것이다. 각 선택 들의 최종 결과 값이 3, 5, 2, 9로 귀결된다고 할 때, Min은 Max의 이득을 최소화 하는 결정을 선택을 하게 될 것이므로, 왼쪽 노드의 3과 5중에서는 3, 오른쪽 노드의 2와 9중에서는 2를 선택할 것이다. 그렇다면 Max 입장에서는 Min이 결정 할 3과 2중에 이득을 최대화 하는 3을 고르게 되는 것이다.

전체 트리 상에는 Max가 이 게임에서 얻을 수 있는 더 큰 이득인 5와 9가 있지만 이들은 Min에 의해 버려지게 될 것이므로, Max 입장에서는 3을 얻기위한 결정을 수행하는 것이 최적이라고 할 수 있다.

변형 Nim 게임에 적용

Nim game은 “베스킨라빈스31” 게임과 유사한 것인데 판에 올려진 물체(코인)을 1개, 2개 혹은 3개씩 돌아가면서 가져가서 결국 마지막 남은 하나를 가져가는 사람이 지게되는 게임이다.

이것을 약간 변형해서 7개의 코인을 가정하고 컴퓨터와 번갈아 가면서 1개, 2개 혹은 3개씩 가져가서 최종적으로 남은 코인을 0개로 만드는 쪽이 이기는 게임을 “변형 Nim 게임”이라고 하고 여기에 minimax를 적용해 보도록 하자.

결정 트리의 모든 노드를 그리면 공간이 부족하니 Max(컴퓨터)가 3개를 가져가는 경우를 탐색하는 상황을 살펴보자. Max와 Min은 각각 번갈아 가면서 코인을 1개, 2개 혹은 3개를 가져가는 상황에 대하여 남은 coin이 0이 되는 상황을 탐색한다.

Max 입장에서 남은 코인이 0개가 되도록 만드는 node가 Min이 되도록 하는 조건이 유리하다고 판단하고, 이 때 큰 점수 +1을 매겨서 결정을 유도하고, 그 반대의 경우에는 -1 점수를 매겨서 이 상황을 피하도록 한다.

구현코드

이러한 트리 탐색 과정을 재귀함수로 나타내면 다음과 같다.

실행 결과 및 결론

다음은 전체 코인의 갯수를 설정하는 total_coins의 값을 12로 해서 수행한 결과이다.

결과를 보면 12 / 8 / 4개를 남기도록 하는 규칙을 명시적으로 주지 않았음에도 컴퓨터는 minimax tree로 부터 이러한 값들이 승부에 유리하다는 것을 탐색해서 항상 이러한 값에 가장 가까운 선택을 하려하는 것 처럼 보이는 약간의 지능적(?) 결과를 볼 수 있다.

아마도 비슷한 글:

  1. Heap tree 만들기
  2. OpenVINO Object Detection Model의 전처리와 후처리를 간단하게
  3. 한글 텍스트 추출을 위한 Python PDF module
  4. OpenVINO python을 이용한 inference 예제

pip 설치 중 컴파일 문제 회피를 위한 잡 기술

댓글 남기기

Python에서 어떤 패키지를 설치하려면 pip를 사용한다.

pip install <패키지>

이상적으로는 이렇게만 하면 편리하게도 pip가 PiPy에서 해당 패키지를 다운로드 해서 개발환경에 설치 해준다. 하지만 실제 pip 설치는 생각보다는 조금 복잡하다. 특히 macOS나 Linux 환경에서는 pip 설치가 기대치 않았던 C/C++ 컴파일 에러라는 새드 엔딩으로 치닫는 경우가 적지 않다.

이 포스팅에서는 pip에서 소스 코드 빌드를 회피하는 방법을 중심으로, pytubefix와 그 의존성인 nodejs-wheel-binaries 사례를 통해 설치를 실행하기 전에 실패를 예측하는 방법과 이를 최대한 회피하는 방법을 정리해 본다. 다만, 설명의 편의를 위해 local wheel 파일을 설치하는 경우는 제외하고 PiPy에서 다운로드 받는 패키지를 가정하고 설명 하였다.

pip 설치에는 두 가지 경우가 있다

pip가 패키지를 설치하는 방식은 크게 두 가지다.

pip install <패키지>
 ├─ wheel(.whl) 파일이 PiPy에 있음 -> 다운로드 후 설치
 └─ wheel 없음 -> 소스 코드 빌드

PiPy에 원하는 버전의 wheel 파일이 존재하면 이것을 다운로드해서 설치하는 것으로 설치 과정이 끝난다. 이것이 바로 앞에서 말한 “이상적인” 경우이다. 만약 wheel이 없으면 pip는 자동으로 소스 빌드를 시도하게 되는데 이렇게 되면 pip 설치 명령어의 성공 여부는 더이상 pip 자체의 문제가 아니라 다양한 변수들의 의존성에 달려있게 된다.

  • OS 버전
  • 컴파일러(clang, gcc)
  • 각종 SDK
  • 외부 라이브러리(OpenSSL 등)

만약 이 모든 요소가 잘 못 얽히게 되면, 복잡 다단한 원인에 의한 컴파일 문제로 결국은 pip 설치 명령어가 실패 할 수도 있다.

설치 전에 컴파일 가능성 판별하기

pip install 명령어의 –dry-run 옵션은 실제로는 설치를 진행하지 않고 모의 실행(Dry run) 해주는 명령어 인데, 이것을 이용하면 컴파일을 필요로 하는 상황인지의 여부를 미리 확인할 수 있다. macOS에서 Pytubefix 패키지를 설치하려는 경우를 예를들어 살펴보자.

pip install pytubefix --dry-run

전술한 대로 이 명령은 실제로 설치를 하지는 않지만, pip가 무엇을 설치하려고 하는지는 그대로 보여 준다. 출력 중에서 주의해서 봐야 할 부분은 다음이다.

이 메세지는 wheel 파일이 없어서 소스 코드 빌드가 시도 됨을 의미한다.

컴파일 회피 하기

컴파일이 항상 실패하는 것은 아니고, 문제가 발생한 경우에도 간단한 의존성 문제를 해결하는 것으로 해결하는 것도 가능하겠지만 때로는 모든 종속성을 해결해 줄 수 없어 차라리 오래된 버전이라도 미리 컴파일 되어 있는 wheel을 사용하고자 할 때도 있다. –only-binary option을 사용하면 설치가 가능한지 여부를 확인할 수 있는데, 다음과 같이 입력하면 직접 컴파일 하지 않고 whl을 다운로드 받아서 설치가 가능한지 여부를 확인할 수 있다.

pip install pytubefix --dry-run --only-binary=:all:

이 옵션은 컴파일 된 wheel이 있는 패키지들로 dry run을 실행해 보라는 의미이다. 성공하면 모든 의존성이 wheel로 제공된다. –only-binary option을 주지 않았을 때에 비해 낮은 버전이 제시된 것을 눈여겨보자. 소스코드 설치는 v24.13.0 이지만 바이너리 설치는 v22.20.0 이다.

만약 이 명령어에서 실패한다면 안타깝게도 의존성이 소스 빌드 없이는 설치가 불가능 함을 의미한다.

실제사례 – Pytubefix

Pytubefix는 YouTube clip를 다운로드 받을 수 있도록 해주던 PyTube가 더 이상 유지 관리가 되지 않으면서 이를 이어받아 진행되고 있는 오픈소스 프로젝트이다. Pytubefix가 Node.js 환경을 독립적으로 관리할 수 있게 해주는 도구인 nodejs-wheel-binaries에 의존 하는데, 문제는 이 모듈이 macOS 13 이상의 버전에 대해서만 wheel을 제공하고 있다는 점이다.

그래서 macOS Monterey(12) 환경에서 pytubefix 설치를 시도하면 지원되는 가장 최신의 nodejs-wheel-binaries 버전인 v24.13.0 소스코드 빌드를 시도하게 되고 이것이 OpenSSL의 deprecated API 때문에 컴파일에 실패하게 된다.

wheel 없음 -> 소스 빌드 -> nodejs-wheel-binaries 컴파일 -> OpenSSL deprecated API -> 컴파일 실패

nodejs-wheel-binaries란?

nodejs-wheel-binaries는 Node.js 런타임을 Python wheel 형태로 패키징한 라이브러리로 Node.js 실행 파일을 Python 가상환경 내부에 포함시켜 pip install만으로 Node.js를 사용할 수 있게 만들어 준다. pytubefix는 YouTube 대응 로직 일부를 JavaScript 기반 코드로 처리하기 때문에 내부적으로 Node.js 실행을 필요로 하기 때문이 이 패키지에 의존한다. 주의할 점은 시스템에 설치한 Node.js의 버전은 이 동작과는 무관하다는 점이다. 즉, 시스템에 Node.js가 설치되어 있다 하더라도, 의존성이 있는 경우에는 이 패키지의 설치가 필요하다.

결론: 소스 빌드를 회피하는 현실적인 해결책

Pytubefix를 위해서는 반드시 최신버전의 nodejs-wheel-binaries 패키지를 사용하지는 않아도 된다. 위에서 pip 명령어로 wheel 파일이 지원되는 것으로 확인한 v22.20.0을 다음의 명령어로 먼저 설치하고 그 위에 pytubefix의 설치를 실행할 수 있다.

pip install "nodejs-wheel-binaries==22.20.0" pytubefix

아마도 비슷한 글:

  1. macOS에서 numpy 설치할 때 빌드 실패 문제
  2. [Tip] Mac version docker에서 띄운 (웹) 서버에 접속하기
  3. macOS terminal로 Emacs 사용 할 때 meta key 변경
  4. MacPorts: Orange3 Text Add-on 추가할 때 오류