무한 리스트로 작성한 피보나치 수열

다음은 Haskell로 정의한 피보나치 수열인데, Haskell의 lazy evaluation을 이해하기 딱 좋다. 코드를 살펴보자.

fibs :: [Int]
fibs = 0 : 1 : zipWith (+) fibs (drop 1 fibs)

fibs는 무한 리스트¹로 정의되는 피보나치 수열이다.² fibs의 0, 1 번째 원소는 이미 평가가 완료된 상태(fully evaluated)이며, 2 번째 이후의 원소는 아직 평가되지 않았다. 이 평가는 해당 값이 필요해지는 시점에 시작된다. 이처럼 값이 필요할 때까지 평가를 미루는 전략을 지연 평가(lazy evaluation)라고 한다.

지연 평가를 채택하면 필요한 시점에만 계산이 수행되며, 필요하지 않은 값은 평가되지 않는다. 이처럼 Haskell은 지연 평가 전략을 채택한 함수형 언어다. 반면, OCaml과 같이 즉시 평가(eager evaluation)을 기본으로 채택한 함수형 언어도 존재한다.

지연 평가 vs. 즉시 평가

지연 평가, 즉시 평가 각각 장단점이 있다. 지연 평가를 사용하면 프로그래머가 계산 순서를 명시적으로 관리할 필요가 없으며, 필요하지 않은 부분은 계산하지 않기 때문에 불필요한 연산을 줄이고 무한한 크기의 자료구조를 쉽게 추상화하여 다룰 수 있다.

다만, 지연 평가는 프로그래머 입장에서 성능을 예상하는게 조금은 난해할 수 있다는 단점이 있다. 메모리 사용 패턴을 제대로 이해해서 설계하지 못한다면 계산이 지연된 표현식들이 폭발적으로 쌓여서 메모리 점유 및 성능상 문제를 일으킨다.

이와 비교해서 즉시 평가는 프로그래머가 계산 순서를 명확히 이해하고 제어할 수 있으므로 최적화가 용이하고 성능에 깊이 개입할 수 있다는 장점이 있다.

비효율적인 메모리 사용으로 인한 성능 저하

n 번째 피보나치 수를 계산하는 함수를 작성해보자. 아까 작성한 피보나치 수열을 활용하면 다음과 같이 naive하게 구현할 수 있다.

fib :: Int -> Int
fib n = fibs !! n

우리는 n 번째 값만 구하면 되지만, fibs의 정의상 1 부터 n-1 까지의 모든 원소를 적어도 한 번씩은 계산해야 한다. 다행히 우리가 정의한 피보나치 함수는 fibs 리스트를 활용하여 일종의 메모이제이션을 달성하기 때문에 \(\text{O}(n)\)의 시간 복잡도를 갖는다.

그러나, 구하고자 하는 표현식인 n 번째 피보나치 수가 최종적으로 평가 완료될 때까지 이들 중간값이 모두 살아있어야 하는 것은 아니다. 중간값들은 리스트의 원소이기도 하기 때문에 garbage collect되지 않고, 결국 \(\text{O}(n)\)의 공간 복잡도를 가진다. 따라서, n이 커지면 cache miss³의 영향으로 성능이 저하된다.

지연 평가로 인한 성능 저하

다음과 같은 코드를 생각해볼 수 있다.

fib :: Int -> Int
fib n = fib' n 0 1
  where
    fib' 0 a _ = a
    fib' k a b = fib' (k - 1) b (a + b)

앞선 예시와 다르게 필요한 중간값들이 모두 함수 인자로 제공되므로 수명이 다한 중간값들이 garbage collect되지 않는 문제는 피할 수 있을 것처럼 보인다.

그러나, 이번에도 n이 커지면 느려진다. 프로파일링 해보면 앞선 예시와 램 사용량, 실행시간 모두 비슷하게 나온다. 이번 예시 또한 \(\text{O}(n)\)의 공간 복잡도를 갖는 것은 아닐까?

원인은 함수의 인자인 a, b⁴가 지연 평가되기 때문이다. 아직 평가되지 않은 표현식이 매우 깊은 트리⁵의 형태로 나타난다. 예를 들어, 다음과 같다.

fib' 1000000 0 1 -->
fib' 999999 1 (0 + 1) -->
fib' 999998 (0 + 1) (1 + (0 + 1)) -->
fib' 999997 (1 + (0 + 1)) ((0 + 1) + (1 + (0 + 1))) -->
fib' 999996 ((0 + 1) + (1 + (0 + 1))) ((1 + (0 + 1)) + ((0 + 1) + (1 + (0 + 1)))) -->
...

결국 \(\text{O}(n)\)의 공간 복잡도를 갖는다. 언뜻 보면 \(\text{O}(2^n)\)처럼 보일 수 있는데, 각 중간 표현식들은 일종의 그래프와 같은 형태를 취하고 있어서 공통된 하위 표현식이 하나의 thunk와 같다. 예를 들어, fib' b (a + b)에서 첫 번째 인수의 b, 두 번째 인수의 b가 모두 같은 thunk다. 따라서 공통된 하위 표현식들은 계산이 완료된 값을 서로 공유한다.

엄격(Strict)한 인수 평가

다음과 같이 인수가 strict하게 평가되도록 강제할 수 있다. Strict한 인수는 지연 평가되지 않고 즉시 평가된다.

fib :: Int -> Int
fib n = fib' n 0 1
  where
    fib' 0 !a !_ = a
    fib' k !a !b = fib' (k - 1) b (a + b)

더이상 인수가 지연 평가되지 않고, 다음과 같이 즉시 평가된다.

fib' 1000000 0 1 -->
fib' 999999 1 1 -->
fib' 999998 1 2 -->
fib' 999997 2 3 -->
fib' 999996 3 5 -->
...

이번 예시는 메모리 사용량이 상수에 해당하며, C++로 작성한 동등한 알고리즘의 코드와 비교하여 메모리는 더 많이 쓰지만 계산 속도는 더 빨랐다. 벤치마크 결과를 다음 링크에서 확인할 수 있다. 벤치마크 결과

참고: 영어로 연산 우선순위는 precedence, 결합 방향은 associativity다.

Haskell에서는 function application과 operation application을 구분한다. Function application의 예시로는 show 123이 있고, operation application의 예시로는 1 + 2, 3 `div` 2 등이 있다.

결합 우선순위는 function application이 operation application보다 항상 높다. 다음은 간단한 예시다.

show 1 + 3    -- Error; (show 1) + 3
show (1 + 3)  -- Ok
show $ 1 + 3  -- Ok, ($) is an operator; show $ (1 + 3)

같은 우선순위 내에서는 결합 방향(associativity)에 따라 괄호를 묶는다. Haskell에서는 결합 방향을 왼쪽(left associative), 오른쪽(right associative), 정의되지 않음(non-associative)의 3가지 경우로 나눌 수 있다.

Function application은 모두 left associative다. 예를 들어, f1 f2 f3은 ((f1 f2) f3)와 같이 왼쪽부터 괄호로 묶인다.

Operation application은 결합 방향을 사용자 정의할 수 있다. 연산자의 결합 방향은 연산이 두 개 이상이어서 a `op1` b `op2` c와 같은 형태일 때 괄호를 치는 방법을 생각하면 결합 방향을 이해할 수 있다. 결합 방향은 infixl, infixr, infix 세 가지로 정의할 수 있다.

infixl의 예시로 +, -, /, *와 같은 산술 연산자를 생각해볼 수 있다. 다음 예시를 살펴보자.

1 + 2 - 3 - 4 == (((1 + 2) - 3) - 4)
1 * 2 * 3 * 4 == (((1 * 2) * 3) * 4)

모두 왼쪽부터 괄호를 치는 것을 알 수 있다. 위 예시는 결합 우선순위가 모두 같은 경우였다. 결합 우선순위가 다른 경우를 살펴보자.

1 + 2 + 3 * 4 == ((1 + 2) + (3 * 4))

+는 infixl 6, *는 infixl 7이므로 *가 우선순위가 높다는 점을 알아두자. 이 경우는 우선순위가 높은 연산이 먼저 결합되고, 그 이후 1, 2, (3 * 4)가 왼쪽부터 괄호로 결합됨을 알 수 있다.

infixr과 infix의 예시도 살펴보자. infixr은 right associative이므로 오른쪽부터 괄호를 묶는다. 예시로 $, ., ->가 있다.

-- Note the precedence and associativity for the following operators:
-- infixr 0 $
-- infixr 9 .

-- TFAE:
show . sum . map read $ ["1", "2"]
show . sum . (map read) $ ["1", "2"]      -- Function application has higher precedence.
(show . sum . (map read)) $ ["1", "2"]    -- (.) has higher precedence than ($).
(show . (sum . (map read))) $ ["1", "2"]  -- (.) is right-associative.
-- Result: "3" :: String

infix의 예시로는 ==이 있다. 결합 방향이 정의되지 않으므로 명시적으로 괄호를 묶어야 한다. 예를 들어, a == b == c는 오류가 발생한다. (a == b) == c 또는 a == (b == c)로 명시적으로 작성해야 한다.

요점: η-reduction을 남발하면 가독성 떨어지는데, 적절하게 쓰면 깔끔하다.

η-reduction은 함수의 인자를 명시하지 않고 함수를 표현하는 방법이다. 예를 들어, f x = g x는 간단하게 f = g로 표현할 수 있다. 주로 함수형 프로그래밍에서 함수의 간결한 작성과 가독성을 위해 자주 사용한다.

-- Ex) makeGreeting "Hello" "Minseo" => "Hello Minseo"
makeGreeting :: String -> String -> String
makeGreeting salutation person =
  salutation <> " " <> person

-- Apply eta reduction once
makeGreeting1 :: String -> String -> String
makeGreeting1 salutation = ((salutation <> " ") <>)

-- Apply eta reduction twice
makeGreeting2 :: String -> String -> String
makeGreeting2 = (<>) . (<> " ")

인자를 명시적으로 사용해 함수를 정의하는 방식을 pointful 스타일이라고 하며, 인자를 생략하고 기존 함수들의 조합만으로 새로운 함수를 정의하는 방식을 pointfree 스타일이라고 한다.

위의 예시에서는 원본 함수가 pointful, eta-reduction 적용한 1, 2번이 pointfree 스타일이다. 그런데 pointful한 원본이 가장 읽기 쉽지 않나? 이 예시에서는 pointfree 스타일이 pointless¹하다. 그냥 아래처럼 명확한 경우만 η-reduction 써야겠다.

addOne :: Int -> Int
addOne x = x + 1

-- Apply eta reduction; much clearer
addOne' :: Int -> Int
addOne' = (+ 1)

요점: flip 안 쓰고 infix operation 활용하는 방법이 있는데, 그게 더 흔한 것 같긴 하다.

타입 시그니처를 살펴보자.

flip :: (a -> b -> c) -> b -> a -> c

두 개의 인자를 받는 함수에서 arg1, arg2의 적용 순서를 arg2, arg1로 바꾼다. type signature를 같이 살펴보면 아주 명확하다. 다음은 적용 예시다.

fn :: T1 -> T2 -> U

val2 :: T2

fn' :: T1 -> U

-- TFAE:
fn' = flip fn val2 -- flip 사용
fn' = (`fn` val2)  -- infix로 표현 후 함수로 변형

Tricky case. 인수를 꼭 2개만 받는 함수여야만 할까? 사실, flip의 arg1인 a -> b -> c에서 c :: * -> *일 수 있다! T1 -> T2 -> T3 -> U인 함수도 T1 -> T2 -> (T3 -> U)로 볼 수 있다.

-- T1 -> T2 -> (T3 -> U)
tn :: T1 -> T2 -> T3 -> U

val2 :: T2

-- T1 -> (T3 -> U)
tn' :: T1 -> T3 -> U
tn' = flip tn val2

질문. flip를 실제로 많이 쓰나? 다음 예시처럼 flip을 굳이 쓰지 않고도 infix operation을 활용할 수 있다.

fn :: T -> String -> U

fn' :: T -> U

-- TFAE:
fn' = flip fn "foobar"  -- flip 사용
fn' = (`fn` "foobar")   -- infix로 표현 후 함수로 변형

infix operation 활용하는게 더 흔할까? flip도 괜찮은 선택일까? 개인적으로는 함수를 infix 이항 연산자로 바라봤을 때 부자연스럽지 않다면, flip보다 연산자로 접근하는 방법이 나은 것 같다.

FreeBSD의 VNET Jail이 무엇인지, 어디에 쓰는지 소개한다. 구성 과정에서 마주칠 수 있는 문제와 해결 방안을 다룬다.

FreeBSD Jail

FreeBSD의 Jail 기능은 프로세스, 파일 시스템, 네트워크, 사용자 및 권한을 격리하는 환경을 제공한다. Linux의 Docker와 비교하자면, Jail은 Docker와 달리 운영체제의 커널 레벨에서 지원하는 기능이다. 따라서 운영체제와 밀접히 통합되어 있으며, 보안 및 안정성, 자원 관리, 네트워크 분리, ZFS 파일 시스템의 활용 등 강력한 장점이 있다.

사실 FreeBSD Jail과 직접적으로 비교할 수 있는 대상은 Docker보다는 LXC가 더 적합해보인다. LXC는 리눅스 커널 차원에서 지원하는 기능이고, 한때 Docker도 LXC를 기반으로 개발되었던 것으로 알고 있다. 지금은 runc라는 별도의 컨테이너 런타임을 사용하고 있다.

Docker는 개발 편의를 위한 도구로써 유용하다. Docker 이미지의 생성 및 레포지토리를 통한 배포 등 개발 환경의 구축을 간소화하고 편의를 제공해주는 도구라는 측면에서 장점이 분명하다. 하지만 모든 컨테이너가 하나의 docker daemon에 의해 관리되고, 이 프로세스가 root 권한으로 실행된다는 점에서 근본적인 보안 문제가 있다.

이를 해결한 Docker의 대안으로는 Podman이 있는데, 각 컨테이너들이 독립적으로 실행되고 이들을 관리하기 위한 daemon 또한 존재하지 않으며, 루트 권한 없이 실행¹되므로 보안상 안전하다. FreeBSD에서도 ocijail 런타임을 활용하여 Podman을 사용할 수 있다. ocijail은 Jail을 활용하여 구현한 컨테이너 런타임이다. 따라서 FreeBSD에서 Docker와 같은 개발 편의 도구가 필요하다면 Podman을 활용할 수 있다.

본론으로 돌아와서, FreeBSD에서는 Podman 등을 사용하지 않아도 기본적으로 제공하는 Jail 기능만 활용하더라도 강력한 격리 환경을 구성할 수 있다.

VNET Jail

A FreeBSD VNET jail is a virtualized environment that allows for the isolation and control of network resources for processes running within it. It provides a high level of network segmentation and security by creating a separate network stack for processes within the jail, ensuring that network traffic within the jail is isolated from the host system and other jails.
– FreeBSD Handbook, 17.2.4. VNET Jails.

VNET Jail은 호스트와 완전히 분리된 네트워크 스택(L2~L7 계층)을 가진다. 즉, 별도의 가상 이더넷 인터페이스(epair, vnet)로 고유한 MAC·L2 링크를 할당받고, 브리지나 VLAN 등 L2 수준에서 자유롭게 구성할 수 있다는 뜻이다. 이로 인해 VNET Jail은 다음과 같은 특징을 갖는다.

1. VM과 마찬가지로 호스트와 별개의 IP를 할당받을 수 있다. 독립된 L2 인터페이스를 통해 호스트와 다른 서브넷에 IP를 붙일 수 있으며, IP aliasing 없이도 완전히 분리된 라우팅·방화벽 정책을 적용 가능하다.

2. 고유의 MAC 주소를 가진 가상 NIC를 사용한다. epair 인터페이스를 통해 L2 프레임을 주고받으며, 브리지(bridge)나 스위치에 직접 연결할 수 있다.

3. 브리지·VLAN·터널링 같은 L2 기능을 그대로 활용할 수 있다. 호스트의 bridge0에 VNET Jail의 인터페이스를 addm 하거나, VLAN 태그를 트렁킹해서 동일한 L2 도메인에 참여시킬 수 있다.

4. 방화벽·라우팅·네트워크 네임스페이스가 호스트와 완전히 분리된다. Jail 내부 전용 방화벽 규칙을 운영하고, routing table을 별도로 관리할 수 있다. Non-VNET Jail에서는 policy-based routing으로 라우팅을 분리할 수 있다.

반면 Non-VNET Jail은 호스트의 물리 NIC가 속한 동일 L2 도메인(같은 MAC 링크)을 공유하고, IP aliasing을 통해 같은 서브넷 내에서만 IP를 할당받는다. 따라서 L2 계층부터 완전 분리가 필요한 경우에는 반드시 VNET Jail을 사용해야 한다.

VNET Jail의 활용

운용 예시를 살펴보면 VNET Jail의 매력을 이해하는 데 도움이 된다. VNET Jail은 호스트와 다른 네트워크 인터페이스를 가지므로 각 Jail을 서로 다른 VLAN에 둘 수 있다. 또한 라우팅 테이블이 호스트와 다르므로 일부 Jail을 특정한 VPN에 연결하도록 구성할 수 있다.

개인적으로 VNET Jail을 활용하여 호스트와 각 Jail에 고유한 IP를 부여하여 다양한 웹 서비스를 운영하고 있다. 또한, dnsmasq로 로컬 DNS 서버를 구축해두고 각 서비스에 서로 다른 로컬 도메인 이름을 매핑해 두었다. 하나의 reverse proxy 아래에 모든 서비스를 두는 방법도 있었지만, 이렇게 네트워크를 구성한 이유는 각 Jail을 물리적으로 구분되는 별도의 서버로 가정해 운영해보고 싶었기 때문이다.

또한 VLAN을 나누어, 각 Jail을 서로 다른 VLAN에 배치하는 구성도 실험하고자 했다. VNET Jail은 호스트 및 다른 VNET Jail들과 각각 독립된 네트워크 인터페이스를 가지기 때문에, 각 Jail을 서로 다른 VLAN에 두면 이들 간의 통신은 반드시 라우터를 거쳐야만 이루어질 수 있다. 이러한 구성을 통해 각 VLAN에 각각 다른 방화벽 정책을 설정하는 등의 실험을 진행할 수 있었다.

홈 네트워크 구성 또한 나중에 기회가 되면 포스팅하겠다.

VNET Jail 구성 방법

VNET Jail은 epair 인터페이스를 생성하여 한 쪽은 브릿지에, 다른 쪽은 Jail에 연결하도록 구성한다.

다음 내용을 /etc/rc.conf에 추가한다.

cloned_interface="bridge0"

ifconfig_bridge0="addm em0 up"

Note. em0와 같은 인터페이스 이름은 기기마다 다를 수 있으니 그대로 사용할 수는 없다.

다음 내용을 /etc/jail.conf에 추가한다.

my-vnet-jail {
# ...

# VNET/VIMAGE
  vnet;
  vnet.interface = "${epair}b";

# NETWORKS/INTERFACES
  $id = "154";
  $ip = "192.168.1.${id}/24";
  $gateway = "192.168.1.1";
  $bridge = "bridge0";
  $epair = "epair${id}";

# ADD TO bridge INTERFACE
  exec.prestart  = "/sbin/ifconfig ${epair} create up";
  exec.prestart += "/sbin/ifconfig ${epair}a up descr jail:${name}";
  exec.prestart += "/sbin/ifconfig ${bridge} addm ${epair}a up";
  exec.start    += "/sbin/ifconfig ${epair}b ${ip} up";
  exec.start    += "/sbin/route add default ${gateway}";
  exec.poststop = "/sbin/ifconfig ${bridge} deletem ${epair}a";
  exec.poststop += "/sbin/ifconfig ${epair}a destroy";
}

자세한 내용은 FreeBSD handbook를 참조한다.

문제점

간혹 Jail을 호스트에서 제거²한 이후에도 epair###b 인터페이스가 Jail에서 release되지 않아서 호스트에서 보이지 않는 문제³가 발생한다. 원래 jail.conf⁴에서 vnet.interface의 인수로 설정한 인터페이스는 자동으로 release되어야 한다.⁵

해결 방법

Jail이 제거되는 시점에 호스트에서 ifconfig -vnet 명령어로 수동으로 인터페이스를 release해줄 수 있다. jail.conf의 exec.prestop 인수에 다음과 같이 명령어를 추가하면 된다.

my-vnet-jail {
# ...

# ADD TO bridge INTERFACE
  exec.prestart  = "/sbin/ifconfig ${epair} create up";
  exec.prestart += "/sbin/ifconfig ${epair}a up descr jail:${name}";
  exec.prestart += "/sbin/ifconfig ${bridge} addm ${epair}a up";
  exec.start    += "/sbin/ifconfig ${epair}b ${ip} up";
  exec.start    += "/sbin/route add default ${gateway}";

  # Add this line
  exec.prestop  += "/sbin/ifconfig ${epair}b || /sbin/ifconfig ${epair}b -vnet $name";

  exec.poststop = "/sbin/ifconfig ${bridge} deletem ${epair}a";
  exec.poststop += "/sbin/ifconfig ${epair}a destroy";
}

• exec.stop은 Jail 제거 시점에 Jail 내부에서 실행된다.
• exec.prestop과 exec.poststop은 각각 Jail 제거 직전과 직후에 호스트에서 실행된다.

Jail 구축 관련 참고 사항

DHCP를 이용한 IP 할당

위에서 소개한 방법은 각 Jail의 IP를 수동으로 할당한다. DHCP를 이용하여 자동 할당받고자 하는 경우, 각 Jail에서 DHCP 클라이언트를 따로 구성해줘야 한다. 또한 jail.conf에서 각 Jail에 대해 일부 restriction을 추가로 해제할 필요가 있던 것으로 기억하는데, 정확한 방법은 기억나지 않는다.

PostgreSQL 등 DB 구축

VNET Jail과 관련은 없으나, PostgreSQL과 같은 일부 데이터베이스⁶를 Jail에서 정상적으로 구동하기 위해서는 해당 Jail에 별도의 restriction을 해제해야 한다. Jail을 소개할 때 언급했듯이, Jail은 각각 자원의 할당 및 권한 관리를 세세히 설정할 수 있다.

PostgreSQL의 경우, sysvipc⁷ restriction을 해제해야 한다. jail.conf 파일에 다음과 같이 추가한다.

my-postgres-jail {
# ...

# PERMISSIONS
  allow.sysvipc;
}

백준 2887번 - 행성 터널의 풀이다.

TL;DR

• 밀집 그래프로 보고 Prim으로 풀면 시간 및 메모리 제한에 걸린다.
• 대부분의 간선들은 MST 알고리즘 실행 전에 미리 제거될 수 있다.
  • \(\left| E \right| = \left| V \right|^2\)에서 \(\left| E \right| = 3\left| V \right|\)까지 줄일 수 있다
• 간선을 대부분 제거하여 희소 그래프가 되므로 Kruskal 알고리즘으로 구현한다.

풀이 과정

문제 전문은 BOJ 웹사이트에서 확인할 수 있습니다. (링크)

문제점

처음에는 그래프가 dense하다고 판단하여 Prim 알고리즘으로 풀 생각이었다. 정점의 좌표가 주어지고, 간선의 가중치를 정점 간 거리로 설정하므로 \(\left| E \right|=\left| V \right|^2\)가 되기 때문이다.

하지만 이렇게 풀었더니 메모리와 시간을 초과했다. 간선 가중치를 미리 계산해 저장하려다가 메모리 초과가 발생했고, 가중치를 정점 좌표로부터 실시간으로 계산해서 얻어오도록 변경했으나 시간 초과가 발생했다.

Prim 알고리즘이 밀집 그래프에 적합하다는 사실을 고려해보면, 문제에서 주어진 그래프를 그대로 MST 알고리즘에 적용할 수는 없었다.

간선 제거 - 1차원 공간

간선의 수를 줄여서 sparse graph로 만들 수 있는지 살펴봤다. 이 문제는 각 정점마다 좌표가 주어지고, 가중치가 정점 간 거리로 정의된다는 점에서 정점을 정렬해볼 수 있었다.

문제를 쉽게 생각하기 위해서 3차원 대신 1차원 공간에서의 정점을 생각해봤다.

정점들을 좌표 순서대로 정렬하면, 직관적으로 MST는 이들을 순차적으로 연결한 리스트의 형태임을 알 수 있다.¹ 즉, MST를 구성하는데 필요한 간선은 좌표로 정렬된 상태에서 인접한 정점들 간의 간선만 포함하면 된다. 이와 같이 1차원 공간에서는 MST를 구성하는 간선 \(\left| V \right|-1\)개를 정확히 찾을 수 있다.

간선 제거 - 3차원 공간

3차원 공간에서는 간선들을 일직선상으로 정렬할 수 없기 때문에, 1차원 공간에서처럼 MST를 구성하는 간선을 정확히 특정하기 어렵다. 그러나, 정점이 3차원 좌표를 갖기 때문에 이를 x, y, z 방향 3개의 성분으로 분리하여 각각 정렬해볼 수는 있다.

위 그림에서 정점 b, c는 x축 성분으로 정렬했을 때 서로 인접한다. 정점 a, c는 y, z축 성분으로 각각 정렬했을 때 서로 인접한다. 정점 a, b는 x, y, z축 성분으로 각각 정렬한 3가지 경우 모두에서 서로 인접한다.

이 모형으로부터 아래와 같은 그래프를 그려보겠다.

이 그래프는 두 정점 사이에 간선을 여러 개 가질 수 있다. 각 간선의 개수는 두 정점을 특정 성분으로 정렬했을 때 서로 인접하도록 하는 성분의 수와 같고, 가중치는 해당 성분에 대한 두 정점의 좌표 차에 해당한다.

문제에서 주어진 그래프를 살펴보면, 간선의 가중치는 두 정점 간의 거리로 정의된다. 좌표가 각각 \((x, y, z)\)와 \((x', y', z')\)인 두 정점 간의 거리는 \(\min \left( \left| x-x' \right|, \left| y-y' \right|, \left| z-z' \right| \right)\)로 정의한다. 이제 이 간선을 가중치가 각각 \(\left| x-x' \right|\), \(\left| y-y' \right|\), \(\left| z-z' \right|\)인 3개의 간선으로 치환해보자. 이렇게 치환하더라도 MST를 구하는 데는 차이가 없다. 두 정점 사이에 여러 개의 간선이 존재할 경우, MST 알고리즘은 항상 최소 가중치의 간선을 선택하기 때문에 결과적으로 동일한 MST가 만들어진다.

따라서, 우리가 그린 그래프는 문제에서 주어진 그래프의 부분 그래프(subgraph)임을 알 수 있다. 이제, 이 부분 그래프에 포함되지 않은 간선은 MST를 구성할 수 없음을 보이겠다. 어떤 간선 \(vw_x\)가 이 부분 그래프에 추가되지 않았고, 그 양 끝 정점 \(v\), \(w\)의 좌표가 각각 \((x, y, z)\)와 \((x', y', z')\)이며, 가중치는 \(\left| x-x' \right| \gt 0\)이라고 가정하자. 이 간선이 부분 그래프에 추가되지 않은 이유는 어떤 정점 \(u\)가 있어서 그 좌표가 \((x'', y'', z'')\)이고 다음을 만족하기 때문이다.

\[ \begin{align*} \left| x\:-x'' \right| &\geq 0 \\ \left| x'-x'' \right| &\geq 0 \\ \left| x\:-x'\: \right| &= \left| x-x'' \right| + \left| x'-x'' \right| \end{align*} \]

\(\left| x-x'' \right|\)와 \(\left| x'-x'' \right|\)이 각각 \(\left| x-x' \right|\)보다 작기 때문에, Kruskal 알고리즘으로 MST를 찾을 때 가중치가 \(\left| x-x' \right|\)인 간선 \(vw_x\)를 선택하는 시점에는 이미 \(v-u-w\) 간의 경로가 존재하게 되어, 이 간선 \(vw_x\)는 선택될 수 없다.  \(\square\)

앞서 구한 부분 그래프는 간선 개수가 \(\left| E \right|=3\left| V \right|\)로, 기존의 \(\left| E \right|=\left| V \right|^2\)에 비해 간선의 수가 훨씬 적은 희소 그래프(sparse graph)다. Kruskal 알고리즘을 사용하여 제한된 메모리와 시간 내에 MST를 구할 수 있었다.

답안

/**
 * @brief BOJ No. 2887 "행성 터널"
 *
 * @author Minseo Kim <kimminss0@outlook.kr>
 * @details 밀집 그래프로 보고 Prim으로 풀면 시간 및 메모리 제한에 걸린다.
 * 이 문제에서 대부분의 간선들은 MST 알고리즘 실행 전에 미리 제거될 수 있는데,
 * |E| = |V|^2에서 |E| = 3|V|까지 줄일 수 있어 사실상 희소 그래프로 풀 수 있기에
 * Kruskal로 구현한다.
 */

#include <algorithm>
#include <iostream>
#include <tuple>
#include <utility>
#include <vector>

using namespace std;

class UnionFind {
private:
  vector<int> parent;

public:
  UnionFind(int N) : parent(N) {
    for (int i = 0; i < N; i++) {
      parent[i] = i;
    }
  }

  int find(int x) {
    if (parent[x] == x) {
      return x;
    }
    // path compression
    return parent[x] = find(parent[x]);
  }

  bool unite(int x, int y) {
    int rootX = find(x);
    int rootY = find(y);
    if (rootX == rootY) {
      return false;
    }
    parent[rootX] = rootY;
    return true;
  }
};

int main(void) {
  cin.tie(nullptr)->sync_with_stdio(false);

  int N;
  cin >> N;

  // idx, coordinate (along the axis)
  vector<pair<int, int>> x(N), y(N), z(N);

  for (int i = 0; i < N; i++) {
    x[i].first = i;
    y[i].first = i;
    z[i].first = i;
    cin >> x[i].second >> y[i].second >> z[i].second;
  }

  if (N == 1) {
    cout << 0;
    return 0;
  }

  // sort by coordinate
  auto cmp = [](pair<int, int> a, pair<int, int> b) -> bool {
    return a.second < b.second;
  };
  sort(x.begin(), x.end(), cmp);
  sort(y.begin(), y.end(), cmp);
  sort(z.begin(), z.end(), cmp);

  // w, v, u
  vector<tuple<int, int, int>> edges;
  edges.reserve(N * 3);
  for (const auto &ax : {x, y, z}) {
    for (int it1 = 0, it2 = 1; it2 < N; it1++, it2++) {
      int v = ax[it1].first;
      int u = ax[it2].first;
      int w = abs(ax[it1].second - ax[it2].second);
      edges.emplace_back(make_tuple(w, v, u));
    }
  }
  // sort by weight, ascending
  std::sort(edges.begin(), edges.end(),
            [](auto a, auto b) -> bool { return get<0>(a) < get<0>(b); });

  // KruskalMST
  UnionFind uf(N);
  int mstWeight = 0;
  for (auto [w, v, u] : edges) {
    if (uf.unite(v, u)) {
      mstWeight += w;
    }
  }
  cout << mstWeight;

  return 0;
}

백준 1197번 - 최소 스패닝 트리의 풀이다.

TL;DR

• 희소 그래프에서는 Kruskal 알고리즘을, 밀집 그래프에서는 Prim 알고리즘을 사용하자.
• Kruskal 알고리즘 구현 시 path compression 하나만으로 효율이 충분히 높아진다.
  • Union-by-rank, path halving은 유의미한 성능 개선이 없었다.

답안

Kruskal

그래프가 sparse할 것 같아서 우선 Kruskal로 구현해봤다. 답안은 다음과 같다.

/**
 * @brief BOJ No. 1197 "최소 스패닝 트리"
 *
 * @author Minseo Kim <kimminss0@outlook.kr>
 * @details Solve minimum spanning tree using Kruskal's algorithm with
 * union-find
 */

#include <algorithm>
#include <iostream>
#include <vector>

using namespace std;

class UnionFind {
private:
  vector<int> parents; // parent's id if non-root; negated rank if root.

public:
  UnionFind(int num_vertices) : parents(num_vertices + 1, 0) {}

  // path halving
  int find(int vertex) {
    // assert vertex > 0
    while (parents[vertex] > 0) {
      if (parents[parents[vertex]] > 0) {
        parents[vertex] = parents[parents[vertex]];
        vertex = parents[vertex];
      } else {
        return parents[vertex];
      }
    }
    return vertex;
  }

  // union
  bool unite(int vertex1, int vertex2) {
    int root1 = find(vertex1);
    int root2 = find(vertex2);

    if (root1 == root2) {
      return false;
    }

    int rank1 = -parents[root1];
    int rank2 = -parents[root2];

    if (rank1 > rank2) {
      parents[root2] = root1;
    } else {
      parents[root1] = root2;
      if (rank1 == rank2) {
        parents[root2]--;
      }
    }
    return true;
  }
};

struct Edge {
  int vertex1;
  int vertex2;
  int weight;
  bool operator<(const Edge &that) const { return this->weight < that.weight; }
};

int main(void) {
  ios_base::sync_with_stdio(false);
  cin.tie(nullptr);

  int num_vertices, num_edges;
  cin >> num_vertices >> num_edges;

  UnionFind uf{num_vertices};
  vector<Edge> edges;
  edges.reserve(num_edges);

  for (int i = 0; i < num_edges; i++) {
    int v, u, w;
    cin >> v >> u >> w;
    edges.emplace_back(Edge{v, u, w});
  }
  sort(edges.begin(), edges.end());

  int mst_weight = 0;
  for (auto [u, v, weight] : edges) {
    if (uf.unite(u, v)) {
      mst_weight += weight;
    }
  }
  cout << mst_weight;
  return 0;
}

Kruskal 알고리즘을 구현하기 위해 union-find 자료구조를 먼저 구현했다. 원래 union-find는 makeset 연산을 지원하지만 위 구현에서는 생성자가 그 역할을 대신하고, 생성자 외부에서 makeset 연산이 필요하지 않기에 public 메서드로 노출할 필요가 없다.

Union-by-rank와 path halving으로 최적화했다. 일반적인 path compression은 재귀 호출 시 call stack이 쌓이는 문제를 피하고 싶었다.

그러나, 사실 최적화는 path compression 하나로도 충분했다. 위 코드에서 path halving 대신 path compression으로 구현을 변경해봤으나 실행시간 및 메모리 사용량 차이가 없었다. union-by-rank 또한 적용하지 않은 것과 차이가 없었다.

Union-by-rank와 path halving이 효과적이지 못했던 이유를 추측하자면, find 연산이 매우 자주 일어나므로 path compression 과정에서 재귀가 깊어지기 어렵고, path compression에 의해 트리의 높이가 매우 낮게 유지되므로 union-by-rank을 하지 않아도 union 이후에 트리의 높이가 유의미하게 증가하지 않기 때문인 듯하다.

Path compression 외 다른 최적화를 적용하지 않은 답안은 이 링크에서 확인할 수 있다.

Prim

희소 그래프에서 Prim과 Kruskal의 성능 차이가 궁금하여 Prim을 추가 구현하였다. Adjacency list와 priority queue로 답안을 작성했다.

#include <algorithm>
#include <iostream>
#include <queue>
#include <utility>
#include <vector>

using namespace std;

int main(void) {
  ios_base::sync_with_stdio(false);
  cin.tie(nullptr);

  int V, E;
  cin >> V >> E;

  vector<vector<pair<int, int>>> adj(V + 1);
  for (int i = 0; i < E; i++) {
    int v, u, w;
    cin >> v >> u >> w;
    adj[v].emplace_back(make_pair(u, w));
    adj[u].emplace_back(make_pair(v, w));
  }

  const int INF = 1000001;
  vector<bool> vertex_in_mst(V + 1, false);
  vector<int> vertex_cost(V + 1, INF);

  vector<pair<int, int>> _data;
  _data.reserve(V + 1);
  for (int i = 1; i <= V; i++) {
    _data.emplace_back(make_pair(i, INF));
  }
  priority_queue pq(
      [](const auto &a, const auto &b) -> bool { return a.second > b.second; },
      std::move(_data));

  int mst_weight = -INF;
  int i = V;
  while (i) {
    const auto [v, w] = pq.top();
    pq.pop();
    if (vertex_in_mst[v])
      continue;
    vertex_in_mst[v] = true;
    mst_weight += w;
    i--;
    for (auto [u, w] : adj[v]) {
      if (w < vertex_cost[u]) {
        vertex_cost[u] = w;
        pq.emplace(make_pair(u, w));
      }
    }
  }
  cout << mst_weight;
  return 0;
}

Edit(2024-09-24): 위 구현에서 priority queue에 모든 vertices에 대해 {i, INF}를 삽입하고 시작하는 것을 볼 수 있다. 그러나 시작 정점 하나만 priority queue에 넣고 시작하는 것이 효율적이다. 구체적으로는 시작 정점 v₀에 대해 cost를 0으로 설정하여 {0, 0}을 삽입하고, mst_weight 또한 -INF 대신 0으로 초기화할 수 있다.

일반적으로 희소 그래프에서는 Kruskal 알고리즘이 Prim 알고리즘보다 효율적이라고 알려져 있다. 실제로 이 문제에서도 메모리 사용량과 실행 시간 모두 Kruskal 알고리즘에 비해 좋지 못했다. 확실히 희소 그래프에서는 힙의 오버헤드와 같은 요인으로 인해 Prim 알고리즘보다 Kruskal 알고리즘이 더 효율적인 것으로 보인다.

PS(Problem Solving) 문제 풀이를 위해 작성한 글입니다. 이론적인 설명은 배제했습니다.

개요

Prim 알고리즘은 minimum spanning tree를 찾는 그리디 알고리즘이다. 임의의 시작 정점에서부터 트리를 성장시키며 MST를 찾으며, priority queue의 이점을 활용한다.

알고리즘

프림 알고리즘은 임의의 시작 정점에서 시작하여 트리를 확장해나가는데, 트리에 인접한 간선 중 최소 비용인 것을 선택한다. 트리에 인접한 최소 가중치 간선을 찾기 위해 연결 비용이라는 개념을 도입한다.

연결 비용은 각 정점에 대해 정의되며, 해당 정점에서 트리와 연결될 수 있는 간선들 중 가장 작은 가중치로 결정된다. 만약 트리와 연결되는 간선이 존재하지 않으면, 연결 비용은 ∞로 설정된다. 트리에 인접한 간선들 중 연결 비용이 가장 작은 정점과 간선을 선택함으로써 최소 가중치의 간선을 찾을 수 있다.

연결 비용을 매번 계산하면 비효율적이므로, 미리 계산해두고 필요시 갱신한다. 구체적으로는 새로운 정점이 트리에 추가되었을 때, 그 정점과 연결된 모든 인접 정점들에 대해 연결 비용을 다시 계산한다.

연결 비용을 다시 계산할 때도 모든 간선의 가중치를 비교할 필요는 없다. 트리에 추가된 정점 \(v\)와 그 인접 정점 \(w\)에 대해, \(w\)의 새로운 연결 비용은 기존 연결 비용과 간선 \(vw\)의 가중치 중 작은 값이다.

자료구조

연결 비용은 priority queue로 관리된다. priority queue는 데이터가 항상 정렬된 상태로 유지되며, 데이터의 삽입과 추출이 빈번한 상황에서 효율적이다. 연결 비용은 자주 갱신되며, 최소값을 반복적으로 검색해야 하므로 priority queue를 사용하는 것이 적합하다.

구체적으로, priority queue는 (정점, 연결 비용, 간선)¹으로 구성된 튜플을 관리한다. 이때 연결 비용이 가장 낮은 튜플이 우선적으로 선택된다. 또한, 연결 비용이나 간선이 갱신될 때마다 새로운 튜플을 priority queue에 삽입한다.

연결 비용과 간선을 직접 수정하지 않고 새로운 튜플을 추가하는 이유는 priority queue에서 이미 삽입된 데이터를 수정하기가 어렵기 때문이다. 또한, 연결 비용은 항상 감소하는 방향으로만 갱신되므로, 새로 삽입된 튜플이 기존의 튜플보다 높은 우선순위를 갖는 것이 보장된다. 추가로, 이전에 삽입된 outdated된 튜플을 무시하기 위해 별도의 lookup list를 사용하여 보완한다.

구현

구현은 BOJ 문제 답안을 참고한다.

• [BOJ] #1197 최소 스패닝 트리

기타

Kruskal vs Prim

Kruskal 알고리즘 또한 MST를 찾는 알고리즘이다. Kruskal은 희소 그래프에서, Prim은 밀집 그래프에서 효율적이라고 알려져 있다. 이는 시간복잡도와도 관련이 있지만 그보다도 Kruskal 알고리즘에 쓰이는 union-find 자료구조가 Prim 알고리즘에서 쓰이는 priority queue보다 overhead가 적기 때문인 것으로 보인다.

시간복잡도만으로는 Kruskal 알고리즘이 희소 그래프에서 효율적인 이유를 설명하기 어려울 수 있다. 두 알고리즘의 시간복잡도는 Kruskal 알고리즘이 \(\text{O}(\left| E \right|\log{\left| E \right|})\), Prim 알고리즘을 이진 힙으로 구현 시 \(\text{O}(\left| E \right|\log{\left| V \right|})\)이다. 정점 개수가 \(\left| V \right|\)인 트리의 간선 수는 \(\left| V-1 \right|\)이므로 임의의 연결 그래프는 \(\left| E \right| \geq \left| V \right|-1\)이기 때문에, 희소 그래프라 하더라도 대부분의 연결 그래프는 \(\left| E \right| \gt \left| V \right|\)이다. \(\left| E \right|\log{\left| E \right|} > \left| E \right|\log{\left| V \right|}\)이므로 Prim 알고리즘이 Kruskal 알고리즘보다 빨라야 한다는 결론이 도출된다.

이는 시간 복잡도만으로 알고리즘의 속도를 평가할 수 없음을 시사한다. Big-O 표기법에서 상수 계수 등은 생략하기 때문이다.

참조

• 프린스턴 대학 알고리즘 강의 - Minimum Spanning Trees
• Wikipedia - Prim’s algorithm

PS(Problem Solving) 문제 풀이를 위해 작성한 글입니다. 이론적인 설명은 배제했습니다.

개요

Kruskal 알고리즘은 minimum spanning tree를 찾는 그리디 알고리즘이다. 간선을 정렬하여 최소 비용 간선부터 선택하며, 이 과정에서 사이클이 형성되지 않도록 한다. 사이클의 형성 여부를 판별하기 위해 Union-find 자료구조를 사용한다.

알고리즘

알고리즘의 핵심은 매 순간 최소 비용 간선을 선택하면서, 사이클이 형성되지 않도록 주의하는 것이다.

매번 최소 비용 간선을 고른다는 점에서 알고리즘이 탐욕적(greedy)임을 알 수 있다. 이런 접근이 가능한 이유는 그래프의 cut property에서 기인한다. 증명 과정은 생략하겠다.

사이클을 피하려면 같은 컴포넌트에 속하는 정점 사이에는 간선을 추가하면 안 된다. 다른 표현으로는, 두 정점 간의 연결성(connectivity)¹를 검사하여 disconnected인 경우에만 간선을 추가할 수 있다. 이와 같은 연결성 문제를 효율적으로 다루기 위해 union-find 자료구조를 사용한다.

위 내용을 정리하면 다음과 같다.

• 간선을 정렬하여 가중치가 작은 간선부터 선택한다.
• 해당 간선을 추가할 때 사이클이 형성되는지 확인한다. 사이클 형성 여부를 확인하기 위해 union-find 자료구조를 사용한다.

자료구조

Union-find

Union-find는 disjoint set²의 collection을 나타내는 자료구조다. 다음 3가지 연산을 지원한다.

• makeset(x): x를 유일한 원소로 두는 새로운 집합 생성. 초기화를 위해 사용.
• find(x): x가 속한 집합을 반환
• union(x, y): x, y가 속한 두 집합을 병합

그래프의 각 컴포넌트는 하나의 disjoint set으로 볼 수 있다. 두 정점이 서로 다른 컴포넌트에 있는지 확인할 때는 find 연산을 사용하고, 간선 {u, v}³를 선택한 이후 두 컴포넌트를 병합하기 위해 union(u, v) 연산을 사용할 수 있다.

Note. Union-find 자료구조는 그래프를 완전히 표현하지 않는다. 정점과 컴포넌트의 소속 관계만 다룰 뿐, 간선 정보는 직접적으로 관리하지 않는다.

의사코드

위에서 논의한 내용을 종합하여 Kruskal 알고리즘을 단계별로 나누면 다음과 같다.

• 그래프의 모든 컴포넌트가 하나의 정점만을 가지도록 초기화한다.
• 가중치가 작은 간선부터 순회한다.
  • 양 끝 정점이 서로 연결되어있는지 확인한다.
  • 연결되지 않았으면, 두 정점이 속하는 컴포넌트를 병합하고 간선은 저장해둔다.
• 간선을 모두 방문한 이후, 저장해둔 간선들은 MST를 이룬다.

다음은 알고리즘의 의사코드다.

function Kruskal(G = (V, E))
    X := {}
    for each vertex u ∈ V
        MAKESET(u)
    for each {u, v} ∈ E ordered by weight increasing
        if FIND(u) ≠ FIND(v)
            add {u, v} to X
            UNION(u, v)
    T := (V, X)
    return T

Union-find의 의사코드는 해당 문서 를 참조한다.

구현

구현은 BOJ 문제 답안을 참고한다.

• [BOJ] #1197 최소 스패닝 트리

기타

Kruskal vs Prim

• Prim 알고리즘 문서 참조 링크

참조

• 프린스턴 대학 알고리즘 강의 - Minimum Spanning Trees
• 블로그 1

PS(Problem Solving) 문제 풀이를 위해 작성한 글입니다. 이론적인 설명은 배제했습니다.

개요

Union-find는 disjoint set¹의 collection을 나타내는 자료구조다. 다르게 표현하면, 집합의 파티션을 나타내는 자료구조다.

Union-find의 주요 개념은 다음과 같다.

• Union-find는 집합을 트리로 나타낸다.
• union은 트리를 합치는 연산이다.
• find는 트리의 root를 찾는 연산이다.
• union by rank, path compression으로 최적화한다.
• rank는 height와 유사하지만 다른 개념이다.
• path splitting과 path halving은 메모리 효율적인 경로 압축 알고리즘이다.

지원하는 연산

Union-find API는 다음 연산을 지원한다.

• makeset(x): x를 유일한 원소로 두는 새로운 집합 생성. 자료구조에 새로운 원소를 추가할 때 사용한다.
• find(x): x가 속한 집합을 반환
• union(x, y): x, y가 속한 두 집합을 병합

Union-find는 집합을 트리 형태로 구현한다. union은 트리를 합치는 연산이고, find는 트리의 root를 찾는 연산이다. 일반적으로 다음과 같이 구현한다.

• find(x)는 root에 도달할 때까지 parent를 타고 올라간다.
• union(x, y)는 두 트리의 root를 찾아 어느 하나를 다른 하나의 자식으로 편입한다.

최적화 기법

find 연산은 flat한 트리에서 더 빠르다. 최악의 경우 트리가 리스트와 같을 수 있으며, 이 경우 find는 모든 노드를 순회한다. 트리의 height를 낮게 유지하는 최적화 기법을 알아보겠다.

Union by rank

union 연산에서 rank가 작은 tree의 root를 rank가 큰 tree의 root의 자식으로 편입한다. 이로써 트리의 rank를 낮게 유지한다.

rank는 height의 upper bound로, height와 일치하지는 않지만 효율을 위해 도입한다. 특징은 다음과 같다.

• 새로 초기화된 node의 rank는 0이다.
• root가 u, v인 두 트리를 병합할 때 다음을 따른다.
  • u, v의 rank가 다르면 작은 것을 큰 것의 자식으로 편입한다.
  • u, v의 rank가 같으면 어느 하나를 부모로 만들고 rank를 1 더한다.
• height와 달리 rank가 업데이트되지 않는 경우:
  • root가 아닌 node는 rank를 업데이트하지 않는다.
  • Path compression 과정에서 height가 변해도 rank를 업데이트하지 않는다.

경로 압축(Path compression)

find 연산 과정에서 트리를 평탄화(flatten)하는 작업을 같이 수행한다. find(x) 호출 시, x와 그 조상들을 한 번에 root로 직접 연결한다. 알고리즘의 설명은 후술한다.

의사코드

다음은 makeset(x)의 의사코드다.

function makeset(x)
    x.parent := x
    x.rank := 0

다음은 union by rank로 구현한 union(x, y)의 의사코드다.

function union(x, y)
    root_x := find(x)
    root_y := find(y)
    if rank(root_x) > rank(root_y)
        root_y.parent := root_x
    else
        root_x.parent := root_y
        if root_x.rank == root_y.rank
            root_y.rank := root_y.rank + 1

다음은 find(x)의 의사코드다. Path compression을 적용하지 않았다.

function find(x)
    while x ≠ x.parent
        x := x.parent
    return x

Path compression을 구현한 find의 의사코드는 다음과 같다.

function find(x)
    if x.parent ≠ x
        x.parent := find(x.parent)
        return x.parent
    else
        return x

재귀 호출로 구현하므로 call stack이 쌓이며 메모리 사용량이 늘어날 수 있다. 재귀 없이 구현하는 방법은 다음과 같다.

function find(x)
    root := x
    while root.parent ≠ root
        root := root.parent

    while x.parent ≠ root
        parent := x.parent
        x.parent := root
        x := parent

    return root

메모리 사용량이 상수값으로 줄어들었다. 다만, root를 찾기 위해 첫 번째 경로 탐색이, path compression을 위한 두 번째 경로 탐색이 발생한다.

한 번만 탐색하는 알고리즘 또한 있다. 단 완전한 경로 압축은 아니고, 메모리 사용 측면에서의 절충안이다. path splitting과 path halving이 있다.

아래는 path splitting 알고리즘이다.

function find(x)
    while x.parent ≠ x
        (x, x.parent) := (x.parent, x.parent.parent)
    return x

아래는 path halving 알고리즘이다.

function find(x)
    while x.parent ≠ x
        x.parent := x.parent.parent
        x = x.parent
    return x

Path splitting은 경로상 모든 부모 노드를 조부모로 연결한다. Path halving은 모든 노드가 아니라 두 번째마다 부모를 조부모로 연결한다. path splitting이 더 공격적으로 경로를 압축하나, 구현이 아주 조금 더 복잡하고 성능 차이는 거의 없다. 따라서 path halving 또한 선호된다.

참조

• Wikipedia - Disjoint-set data structure
• 블로그 1