seokyoung

[Algorithm] 이분 탐색 - 심화

seok-young — Tue, 21 Jan 2025 16:01:45 +0900

이분 탐색을 활용한 Parametric Search 문제에서 정말 다양한 코드들이 존재한다.

우선 종료 조건에 따라, ~~st < en~~과 ~~st <= en~~으로 분리된다.

또한, 구간 업데이트 시, ~~st = mid + 1~~, ~~st = mid~~ 혹은 ~~en = mid - 1~~, ~~en = mid~~ 과 같은 다양한 코드들을 마주하게 된다.

이들의 조합을 생각해 보면 정말 수많은 조합이 가능해진다.

실제로 PS에서 이런 종료 조건들에 의해 답이 틀리는 경우도 있었으며, 무한 루프에 빠지는 경험을 자주 하곤 했다.

이에 따라 이들의 차이점에 대해 정리하고자 한다.

아래의 나오는 코드들은 Swift로 작성되었다.

이분 탐색

"이분 탐색"은 정렬되어 있는 원소들에서 탐색 범위를 절반으로 줄여가며 탐색하는 알고리즘이다.

func binarySearch<T: Comparable>(elements: [T], target: T) -> Int? {
  var st = 0
  var en = elements.count - 1
  
  while st <= en {
    let mid = (st + en) / 2
    
    if elements[mid] == target {
      return mid
    } else if elements[mid] > target {
      en = mid - 1
    } else {
      st = mid + 1
    }
  }
  
  return nil
}

이때의 핵심은 탐색의 범위를 반씩 줄여간다는 것이다.

예를 들어, [st, en]의 범위에서 mid가 작거나 크다면,

mid를 포함한 나머지 구간은 탐색에서 제외시켜 버린다.

이렇게 매 횟수마다 절반씩 줄여나가기 때문에, 시간복잡도는 $O(logN)$이 된다.

Parametric Search

“Parametric Search”란 특정 조건을 만족하는 값 중 최적값을 찾는 알고리즘이다.

이분 탐색에서는 특정 조건을 만족하는 값을 찾는 문제인 반면, 파라메트릭 서치는 이 중 최적값을 찾는 문제이다.

파라메트릭 서치의 핵심은 최적화 문제를 결정 문제로 바꾸어 푼다는 점이다.

최적화 문제: 가능한 해 중 가장 최적의 해를 찾는 것 (3보다 큰 최초의 수)
결정 문제: 주어진 조건에 해가 존재하는지 여부를 판단하는 것 (3보다 작다 크다.)

예를 들어, [1, 2, 3, 4, 4, 4, 5] 의 배열에서 최초의 4가 등장하는 인덱스를 찾는다고 가정해 보자.

이를 결정 문제로 바꾸게 되면, "k번째 인덱스가 4보다 큰가?"라는 문제로 바뀌게 된다.

이 K에 대해서 이분 탐색으로 바꿔서 풀게 되면 결정문제로 해를 구할 수 있게 된다.

Parametric Search는 이분 탐색과 다르게 원하는 조건과 동일한 값이 나오더라도,

최적해를 구하는 문제이기 때문에, 해가 아닐 수 있다.

위의 예시에서 5번 인덱스의 4를 먼저 발견했다고 해서, 최초의 4를 보장할 수 없듯이 말이다.

이러한 Parametric Search를 활용하는 대표적인 것에는 lowerBound, upperBound 등등 이 있다.

구간의 범위

Parametric Search문제에서는 구간을 어떻게 설정하느냐에 따라, 종료 조건 혹은 탐색의 범위를 줄여나가는 방식에 차이가 있을 수 있다.

이러한 구간에는 다음과 같은 방법들이 존재한다.

닫힌 구간: [st, en]
반열린 구간: [st, en)
열린 구간: (st, en)

대부분 닫힌 구간, 반열린 구간을 많이 사용하기에 해당 포스팅에선 2가지 방식만 다룰 것이다.

아래 사용하는 예시들은 lowerBound를 기준으로 코드를 작성했다.

닫힌 구간

닫힌 구간에서의 코드를 우선적으로 살펴보자.

func lowerBound<T: Comparable>(elements: [T], target: T) -> Int {
  var st = 0
  var en = elements.count - 1
  
  while st <= en {
    let mid = (st + en) / 2
    
    if elements[mid] < target {
      st = mid + 1
    } else {
      en = mid - 1
    }
  }
  
  return st
}

닫힌 구간이기 때문에, ~~mid~~를 기준으로 다음과 같이 2개의 닫힌 구간으로 분할된다.

[st, mid]
[mid, en]

이분 탐색과 마찬가지로, mid에서의 탐색을 한 후, 다음 탐색에선 mid를 제외시켜 버리게 된다.

따라서, 아래와 같이 업데이트 되어야 한다.

[st, mid - 1]: ~~en = mid - 1~~로 업데이트
[mid + 1, en]: ~~st = mid + 1~~로 업데이트

종료 조건

닫힌 구간에서 종료 조건은 다음과 같다.

while st <= en

이는, 닫힌 구간이기에, [k, k]의 범위에서도 k라는 숫자가 존재한다. 즉, 검사해주어야 하는 숫자가 존재한다.

또한, 탐색의 끝 값도 유효한 해가 될 수 있기에 검사를 해주어야 한다.

주의할 점

닫힌 구간에서 주의할 점은 탐색이 종료된 후, ~~st != en~~ 이 된다.

따라서, 문제 조건에 맞게 st를 리턴할지, en을 리턴할지 혹은 st - 1, en -1을 리턴할지 고려해야 한다.

예를 들면 lowerBound의 경우에는 st를 리턴했던 반면, upperBound에서는 en을 리턴해야 한다.

func upperBound<T: Comparable>(elements: [T], target: T) -> Int {
  var st = 0
  var en = elements.count - 1
  
  while st <= en {
    let mid = (st + en) / 2
    
    if elements[mid] <= target {
      st = mid + 1
    } else {
      en = mid - 1
    }
  }
  
  return en
}

반열린 구간

func lowerBound<T: Comparable>(elements: [T], target: T) -> Int {
  var st = 0
  var en = elements.count
  
  while st < en {
    let mid = (st + en) / 2
    
    if elements[mid] < target {
      st = mid + 1
    } else {
      en = mid
    }
  }
  
  return en
}

가장 큰 특징으로는 반열린 구간이기에, ~~en = elements.count~~로 설정해주었다.

반열린 구간에서는 [st, en)이 ~~mid~~값을 기준으로 다음과 같이 2개의 열린구간으로 분할된다.

[st, mid)
[mid, en)

반열린 구간 역시 이분 탐색과 마찬가지로, mid 검사 이후 다음 탐색에서 mid는 구간에서 제외되어야 한다.

이로 인해, 다음 범위는 다음과 같이 설정된다.

[st, mid): ~~en = mid~~ 로 업데이트
[mid + 1, en): ~~st = mid + 1~~로 업데이트, mid를 제외시켜야 하기 때문에 위와 같이 업데이트한다.

종료 조건

반열린 구간에서의 종료 조건은 다음과 같다.

while st < en

이는 [k, k)를 만족하는 자연수 k는 존재하지 않는다. 따라서, 두 값이 같을 때의 별도의 탐색을 필요 없게 된다.

반열린 구간의 장점은 탐색 종료 시에는 ~~st == en~~이기 때문에 어떠한 값을 리턴해도 상관없다는 장점이 있다.

[Design Pattern] Coordinator - Refactoring

seok-young — Fri, 17 Jan 2025 15:55:57 +0900

기존 Coordinator에서는 몇 가지 문제점들과 불편한 점들을 겪고 이들을 리팩토링의 필요성을 느꼈다.

이전 버전의 Coordinator는 여기서 확인해볼 수 있다.

https://seokyoungg.tistory.com/100

[Design Pattern] Coordinator 패턴

"Coordinator패턴"은 ViewController로부터 화면 전환의 부담을 줄여주기 위한 패턴이다. 이를 통해ViewController 간의 결합도를 낮춰주게 된다. 만약 ViewController에서 다음과 같이 화면 전환 로직을 담

seokyoungg.tistory.com

결과물을 SPM을 통해 배포했기 때문에, 사용법 및 코드들은 아래서 확인해 볼 수 있다.

https://github.com/jungseokyoung-cloud/Coordinator

GitHub - jungseokyoung-cloud/Coordinator: Coordinator 패턴

Coordinator 패턴 . Contribute to jungseokyoung-cloud/Coordinator development by creating an account on GitHub.

github.com

기존 Coordinator 구조의 문제점

기존 Coordinator 구조

기존 Coordinator는 다음과 같은 BaseCoordinator가 존재하여, 필요한 곳에서 이를 채택해 활용했다.

/// 화면 전환 로직 및, `ViewController`와 `ViewModel`생성을 담당하는 객체입니다.
public protocol Coordinating: AnyObject {
  var navigationController: UINavigationController? { get set }
  var children: [Coordinating] { get }
  
  func start(at navigationController: UINavigationController?)
  func stop()
  func addChild(_ coordinator: Coordinating)
  func removeChild(_ coordinator: Coordinating)
}

open class Coordinator: Coordinating {
  public var navigationController: UINavigationController?
  public final var children: [Coordinating] = []
  
  public init() { }
  
  public init(_ navigationController: UINavigationController?) {
    self.navigationController = navigationController
  }
  
  open func start(at navigationController: UINavigationController?) {
    self.navigationController = navigationController
  }
  ...
}

활용

실제 사용방법은 다음과 같다.

우선, Coordinator를 채택해주게 된다.

import UIKit
import Core

final class SignUpCoordinator: Coordinator, SignUpCoordinatable {
  ...
  
  override func start(at navigationController: UINavigationController?) {
    super.start(at: navigationController)
    attachEnterEmail()
    // navigationController.pushViewController(viewController)
  }
}

이후, 시작되었을 때의 원하는 동작을 ~~start(at:)~~메서드에 구현해 주면 된다.

이때, ~~SignUpCoordinator~~와 같이 Coordinator의 구현체들을 Internal타입이기 때문에, 외부 모듈로 노출되지 않게 된다.

활용 - 부모 coordinator

앞서 말했은 Coordinator들의 구현체들은 Internal타입이기 때문에, 부모 Coordinator에선 이를 ~~Coordinating~~이라는 프로토콜 타입으로 알고 있게 된다.

final class LogInCoordinator: Coordinator {
  ...
  
  private var signUpCoordinator: Coordinating?

부모에선 이를 통해 Routing을 진행하고 싶다면, 아래와 같이 진행한다.

// MARK: - SignUp
func attachSignUp() {
  guard signUpCoordinator == nil else { return }

  let coordinater = signUpContainable.coordinator(listener: self)
  addChild(coordinater)
  
  self.signUpCoordinator = coordinater
  // 이를 호출하면, navigationController에 띄어지게 됨.
  coordinater.start(at: self.navigationController) 
}

우선, 중복되어 View가 Present되는 것을 방지하기 위해 guard문을 통해 확인해 준다.

최종적으로 자식 Coordinator의 ~~start(at:)~~메서드를 호출한다.

문제점

앞선, 구조로 프로젝트에서 4~5개월간 사용해 보면서 다음과 같은 문제점을 느끼게 되었다.

한 가지 방식으로만 Routing이 가능한 문제
사용하는 곳이 아닌 사용되는 Coordinator에서 Routing방식을 결정하는 문제점
UIKit에 대한 의존성 문제

한 가지 방식으로만 Routing할 수 있는 문제점

우선, 가장 큰 문제점은 한가지 방식으로만 Routing 할 수 있다는 문제점이다.

final class SignUpCoordinator: Coordinator, SignUpCoordinatable {
  ...
  
  override func start(at navigationController: UINavigationController?) {
    super.start(at: navigationController)
    attachEnterEmail()
    // navigationController.pushViewController(viewController)
  }
}

앞서 말했는 부모는 자식을 Coordinating으로만 알고 있게 된다.

final class LogInCoordinator: Coordinator {
  ...
  
  private var signUpCoordinator: Coordinating?

따라서, 다른 Routing방식을 위해 메서드를 추가가 불가능하다.

그렇다고, Interafce에 Routing 방식마다 메서드를 추가해 놓자니, 구체 타입에서 구현을 하지 않게 되는 메서드들이 생기게 된다. 즉, LSP에 위반하게 된다.

사용하는 곳이 아닌 사용되는 Coordinator에서 Routing 방식을 결정하는 문제점

두 번째는 사용하는 곳이 아닌 사용되는 Coordinator에서 아래와 같이 Routing방식을 결정하게 된다.

override func start(at navigationController: UINavigationController?) {
  super.start(at: navigationController)
  
  navigationController?.present(viewController, animated: true)
}

다음과 같은 예시를 들어보자.

'LogIn' 화면에서 "회원가입하기" 버튼을 누르게 되면 'SignUp'으로 넘어가게 된다.

이때, Routing방식은 실제 해당 View를 띄우는 'Login'에서 결정하는 것이 아닌 'SignUp'에서 결정 나게 된다.

해당 문제점은 앞서 말한, "한가지 방법으로만 Routing이 가능한 문제점"과 더불어, 결론적으로 View의 재사용성을 저하시키게 된다.

또한, 'Login'에서 'SignUp'이 띄어지는 방식이 modal 방식으로 변경되었다고 가정해 보자.

그렇다면, 'Login'을 수정하는 것이 아닌, 'SignUp'을 수정해야 한다.

즉, 변경의 범위가 'SignUp'까지 확대되는 문제가 발생한다.

추가적으로 UISegmentControl에서 segment가 바뀔 때마다 ViewController가 변경된다고 가정해 보자.

그렇다면, UISegmentControl를 가지고 있는 ViewController에선 각 segment별로 ViewController를 알고 있어야 한다.

하지만, 사용되는 Coordinator에서 Routing방식을 결정하기 때문에, ViewController를 알지 못한다.

지금까지는 이를 해결하기 위해 임시방편으로 Coordinator의 ViewController프로퍼티를 다음과 같이 Internal로 구현해 놓았다.

// 부모
final class ChallengeCoordinator ... {
 func attachSegments() {
   let feedSegmentCoordinator = feedSegmentContainer.coordinator(listener: self)
   // 부모는 Coordinating으로 알고 있기에 타입 캐스팅이 필요함.
   guard let feedSegmentCoordinator = feedSegmentCoordinator as? FeedSegmentCoordinator else { return }
   self.feedSegmentCoordinator = feedSegmentCoordinator
   viewController.attachViewControllers(feedSegmentCoordinator.viewController)
 }
}

// 자식
final class FeedSegmentCoordinator ... {
  let viewController: FeedSegmentViewController
  ...
}

만약, 부모 자식이 모두 같은 모듈에 존재한다면 internal로 해결이 가능하지만, 다른 모듈일 경우엔 불가능하다.

viewController 프로퍼티를 public으로 변경한다 해도, Coordinator는 Internal타입이기 때문이다.

UIKit에 대한 의존성 문제

마지막으로는 Coordinator에서 UINavigationController로 인해 UIKit에 대한 의존성이 생긴다는 문제점이다.

리팩토링

앞선, 문제점들을 다시 정리해 보자.

한 가지 방식으로만 routing 할 수 있는 문제
사용되는 Coordinator에서 Routing방식을 결정하는 문제
UIKit에 대한 의존성

이를 해결하기 위해, 가장 핵심은 ViewController를 외부에서 접근할 수 있게 하는 것이다. 이렇게 되면, 부모 Coordinator에서 어떤 방식으로 Routing 할지 결정할 수 있어 재사용성이 증가하게 된다.

UIKit에 대한 의존성

ViewController를 외부로 분리하기에 앞서, UIKit에 대한 의존성을 제거해 보자.

이를 달성하기 위해 다음과 같은 2개의 타입들을 추가했다.

~~ViewControllerable~~: UIViewController를 랩핑 한 프로토콜 타입이다.
~~NavigationControllerable~~: UINavigationController를 랩핑한 객체이다.

ViewControllerable

이는 RIBs 아키텍쳐의 ViewControllerable을 참고했다.

public protocol ViewControllerable: AnyObject {
  var uiviewController: UIViewController { get }
}

public extension ViewControllerable where Self: UIViewController {
  var uiviewController: UIViewController { return self }
}

하지만, 이는 다음과 같은 방식으로 present를 하기 때문에 코드가 복잡해진다는 단점이 존재한다.

let viewController = coordinator.viewControllerable.uiViewController 
viewController.modalPresentationStyle = .fullScreen 
self.viewControllerable.present(viewController, animated: true)

따라서, 편리성을 위해 extension을 통해 다음과 같이 구현해 주었다.

// MARK: - Present Methods
public extension ViewControllerable {
  func present(
    _ viewControllable: ViewControllerable,
    animated: Bool,
    completion: (() -> Void)? = nil
  ) {
    self.uiviewController.present(
      viewControllable.uiviewController,
      animated: animated,
      completion: completion
    )
  }
  
  func present(
    _ viewControllable: ViewControllerable,
    animated: Bool,
    modalPresentationStyle: UIModalPresentationStyle,
    completion: (() -> Void)? = nil
  ) {
    viewControllable.uiviewController.modalPresentationStyle = modalPresentationStyle
    self.uiviewController.present(
      viewControllable.uiviewController,
      animated: animated,
      completion: completion
    )
  }
...
}

또한, present뿐만이 아닌 push방식을 고려하여 다음과 같이 추가해 주었다.

// MARK: - Push Methods
public extension ViewControllerable {
  func pushViewController(_ viewControllable: ViewControllerable, animated: Bool) {
    if let nav = self.uiviewController as? UINavigationController {
      nav.pushViewController(viewControllable.uiviewController, animated: animated)
    } else {
      self.uiviewController
        .navigationController?
        .pushViewController(viewControllable.uiviewController, animated: animated)
    }
  }

NavigationControllerable

만약, Coordinator에서 다음 View를 Navigation으로 감싸 present하고 싶은 경우 ~~UINavigationController~~를 생성해주어야 한다.

따라서, 이를 랩핑 해주는 NavigationControllerable을 추가해 주었다.

public extension ViewControllerable where Self: NavigationControllerable {
  var uiviewController: UIViewController { return self.navigationController }
}

@MainActor
public class NavigationControllerable: ViewControllerable {
  public let navigationController: UINavigationController
  
  // MARK: - Initializers
  public init(navigationController: UINavigationController) {
    self.navigationController = navigationController
  }
  
  public init(_ rootViewControllerable: ViewControllerable) {
    self.navigationController = UINavigationController(rootViewController: rootViewControllerable.uiviewController)
  }
  
  public init() {
    self.navigationController = UINavigationController()
  }
}

ViewController를 외부로 노출시키기

이제, 위의 ViewControllerable을 활용해 Coordinator에서 ViewController를 외부로 노출시켜 보자.

이에 앞서, 특정 Coordinator에선 ViewController가 필요 없는 경우가 있다.

예를 들어, SignUp에는 여러 단계들이 포함될 수 있다. (아이디 입력, 비밀번호 입력 …)

이들을 묶어주는 SignUp에는 별도의 ViewController가 필요 없어지게 된다.

따라서, 이들을 분리해 주기 위해 Coordinator를 2가지 타입으로 분리했다.

~~Coordinator~~: View가 없는 Coordinator
~~ViewableCoordinator~~: View가 있는 Coordinator

Coordinator

/// 화면 전환 로직을 담당하는 객체입니다..
public protocol Coordinating: AnyObject {
  var children: [Coordinating] { get }
  
  func start()
  func stop()
  func addChild(_ coordinator: Coordinating)
  func removeChild(_ coordinator: Coordinating)
}

open class Coordinator: Coordinating {
  public final var children: [Coordinating] = []
    
  /// 부모에게 attach되었을 때 원하는 동작을 해당 메서드에 구현하면 됩니다.
  open func start() { }
  
  /// 부모에게 제거되었을 때 원하는 동작을 해당 메서드에 구현하면 됩니다.
  open func stop() {
    self.removeAllChild()
  }
  
  public init() { }
  
  public final func addChild(_ coordinator: Coordinating) {
    guard !children.contains(where: { $0 === coordinator }) else { return }
    
    children.append(coordinator)
    
    coordinator.start()
  }
  
  public final func removeChild(_ coordinator: Coordinating) {
    guard let index = children.firstIndex(where: { $0 === coordinator }) else { return }
    
    children.remove(at: index)
    
    coordinator.stop()
  }
  
  private func removeAllChild() {
    children.forEach { removeChild($0) }
  }
}

View가 없기 때문에, 기존의 Coordinator와 NavigatoinController가 없다는 것 외에 차이점이 없다.

ViewableCoordinator

다음은 View가 있는 경우의 Coordinator이다.

public protocol ViewableCoordinating: Coordinating {
  var viewControllerable: ViewControllerable { get }
}

인터페이스는 ~~viewControllerable~~가 추가되었다.

이를 통해 부모에서는 Routing을 담당하게 된다.

또한, Coordinator에서 ViewController로 이벤트를 전달할 경우가 발생한다. 이전 방식에선 이를 구체타입으로 해결했었다.

이를 해결하고자 다음과 같이 구현했다.

open class ViewableCoordinator<PresenterType>: Coordinator, ViewableCoordinating

public let viewControllerable: ViewControllerable
  /// 내부적으로 `Coordinator`에서 `ViewController`로 이벤트를 전달할 경우 사용합니다.
public let presenter: PresenterType

public init(_ viewController: ViewControllerable) {
  self.viewControllerable = viewController
  
  guard let presenter = viewController as? PresenterType else {
    fatalError("\(viewController) should conform to \(PresenterType.self)")
  }
  
  self.presenter = presenter
  super.init()
  bind()
}

viewControllerable은 부모에서 Routing을 하기 위해 사용된다.

또한, presenter는 내부에서 ViewController로 이벤트를 전달하기 위해 사용한다.

이때, 부모는 ViewableCoordinating이라는 인터페이스로만 알기 때문에, presenter에 접근할 수 없다.

[iOS] Custom 영상길이 조절 SliderBar 구현하기

seok-young — Sat, 14 Dec 2024 01:07:57 +0900

이번 포스팅에선 아래와 같이 iPhone에서 제공하는 SliderBar를 직접 구현해보자!

자세한 것은 해당 링크에서 확인해볼 수 있습니다.

https://github.com/jungseokyoung-cloud/VideoTrimmingSliderBar

GitHub - jungseokyoung-cloud/VideoTrimmingSliderBar

Contribute to jungseokyoung-cloud/VideoTrimmingSliderBar development by creating an account on GitHub.

github.com

우선, 해당 ~~VideoTrimmingSliderBar~~를 State를 정의할 수도 있고, send-Action을 활용할 수 있어, UIControl로 구현해주었다.

final class VideoTrimmingSliderBar: UIControl { ... }

기본적인 프로퍼티들부터 보자면, 다음과 같다.

/// 현재 slider의 최솟값
private var minimumValue: Double = 0
/// 현재 slider의 최댓값
private var maximumValue: Double = 100

/// 현재 slider에서 선택학 영역의 최솟값
private(set) var lowerValue: Double = 0.0 {
  didSet {
    updateThumbFrame(lowerSlider)
    delegate?.lowerValueDidChanged(self, value: lowerValue)
  }
}

/// 현재 slider에서 선택한 영역의 최댓값
private(set) var upperValue: Double = 100 {
  didSet {
    updateThumbFrame(upperSlider)
    delegate?.upperValueDidChanged(self, value: upperValue)
  }
}

영상 길이 조절 기능

영상길이를 조절할 수 있는 것은 다음과 같이 구성된다.

우선, 좌우에서 영상 길이를 조절할 수 있는 ~~sliderThumb~~와

~~sliderThumb~~ 사이 길이에 맞춰 길이가 늘어나고 줄어드는 ViewA가 있다.

해당 ViewA와 좌우의 ~~sliderThumb~~를 하나로 묶을 수 있지만,

실제로 움직이는 곳은 ~~VideoTrimmingSliderBar~~이기 때문에,

묶게 되면 좌 우 ~~sliderThumb~~의 위치 파악이 어려워지는 단점이 있다.

따라서, VideoTrimmingSliderBar안에 다음과 같이 2개의 Thumb를 별도로 구성해주어야 한다.

private let lowerThumb = SliderThumb(tintColor: .systemYellow)
private let upperThumb = SliderThumb(tintColor: .systemYellow)

View A의 UI

다음으로 ViewA를 그려보자. 이때 View를 그리는 방법에는 크게 3가지로 구상했다.

UIView

가장 간단한 방법의 UIView로 구성하는 것이다.

말그대로 너무나 간단하고 동작역시 매끄럽다.

private let topView = UIView()
private let bottomView = UIView()

func updateThumbFrame(_ thumb: SliderThumb) {
  ...
  updateTopAndBottomView()
}


func updateTopAndBottomView() {
  topView.frame = CGRect(
    x: lowerThumb.center.x,
    y: 0,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
  
  bottomView.frame = CGRect(
    x: lowerSlider.center.x,
    y: bounds.height - 5,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
}

Core Graphics

다음 방법으로는 CPU기반 렌더링 방식인 Core Graphics다.

// MARK: - Draw
override func draw(_ rect: CGRect) {
  super.draw(rect)
  guard let context = UIGraphicsGetCurrentContext() else { return }
  
  let maskedRect = CGRect(
    x: lowerThumb.center.x,
    y: 0,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
  
  context.setFillColor(UIColor.systemYellow.cgColor)
  context.fill(maskedRect)
}

이것 역시 매끄럽고 잘 동작한다.

Core Animation

마지막으로 Core Animation방식이다.

Core Animation에선 다음과 같이 구성된다.

func updateThumbFrame(_ thumb: SliderThumb) {
  ...
  updateTopAndBottomLayer()
}


func updateTopAndBottomLayer() {
  topLayer.frame = CGRect(
    x: lowerThumb.center.x,
    y: 0,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
  
  bottomLayer.frame = CGRect(
    x: lowerThumb.center.x,
    y: bounds.height - 5,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
}

하지만, 해당 방식에서는 다음과 같은 Delay가 존재하게 되었다.

GPU 기반의 랜더링인 Core Animation이 CPU기반의 Core Graphics보다 빠르면 더 빨랐지, 느릴일은 없다고 생각했다. 하지만 위와 같은 딜레이를 맞이하고 stackOverFlow에 질문글을 올리게 되었다.

https://stackoverflow.com/questions/79264407/why-does-core-animation-have-a-delay-compared-to-core-graphics

Why does Core Animation have a delay compared to Core Graphics?

I am trying to implement a custom UISlider on an iOS device. First, the ThumbSlider is positioned on both ends, and the desired behavior is as follows: When the ThumbSlider moves left or right, the

stackoverflow.com

해당 답변에 의하면, Core Animation에서는 implicit하게 animation을 실행하는 것들이 있으며, frame이 이에 해당된다. 따라서, 위의 딜레이는 Animation에 의한 딜레이이고, 이를 해결하기 위해선 다음과 같이 코드를 작성해야 한다.

func updateTopAndBottomLayer() {
  CATransaction.begin()
  CATransaction.setValue(kCFBooleanTrue, forKey: kCATransactionDisableActions)
  topLayer.frame = CGRect(
    x: lowerThumb.center.x,
    y: 0,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
  
  bottomLayer.frame = CGRect(
    x: lowerThumb.center.x,
    y: bounds.height - 5,
    width: upperThumb.center.x - lowerThumb.center.x,
    height: 5
  )
  CATransaction.commit()
}

Core Animation 선정 이유

우선적으로, 해당 View는 아무런 이벤트가 없기 때문에, Responder Chain을 활용할 이유가 없다고 생각했다.

또한, UIView는 Core Animation과 Core Graphics보다 무겁다.

따라서, UIView의 방식은 우선적으로 배제했다.

다음으로 Core Graphics방식과 Core Animation 방식이다.

해당 ViewA는 ThumbSlider가 움직일때마다, drawing이 일어나게 된다.

즉, 자주 일어나기 때문에, CPU기반보단 GPU기반이 성능적의 이점이 있다고 판단했다.

실제 테스트 해봤을 때의 결과는 CPU 사용률은 1~2퍼 정도만 차이가 났다.

그럼에도 불구하고, 조금이나마의 성능 최적화를 위해 Core Animation으로 선정했다.

Core Graphics (최대 7)

Core Animation (최대 6)

UIView (최대 8)

위치 계산

다음으로는 ~~ThumbSlider~~를 움직였을 때의 위치 변환이다.

View 좌표계를 초 단위로 변경

앞서 살펴보았듯, ~~ThumbSlider~~의 값들은 lowerValue, upperValue로 들고 있으며 이들은 초단위이다.

하지만, 이때 움직이는 것은 View의 좌표계 단위로 움직이기 때문에, 이들을 초단위로 매핑해주어야 한다.

우선 다음과 같이 ~~UIControl~~의 ~~continueTacking(_:with:)~~ 메서드에 다음을 추가해주자.

override func continueTracking(_ touch: UITouch, with event: UIEvent?) -> Bool {
  let location = touch.location(in: self)
  defer { previousLocation = location }
  
  guard let thumb = currentHighlightedThumb else { return false }
  
  let thumbDeltaValue = deltaValue(from: previousLocation, to: location)
  
  
  if thumb === lowerThumb {
    self.lowerValue = updatedLowerValue(moved: thumbDeltaValue)
  } else if thumb === upperThumb {
    self.upperValue = updatedUpperValue(moved: thumbDeltaValue)
  }
  sendActions(for: .valueChanged)
  
  return true
}

해당 동작을 살펴보면 다음과 같다.

let sliderDeltaValue = deltaValue(from: previousLocation, to: location)

func deltaValue(from previous: CGPoint, to current: CGPoint) -> Double {
  let deltaLocation = Double(current.x - previous.x)
  
  return (maximumValue - minimumValue) * deltaLocation / Double(totalLength)
}

움직인 거리를 초단위로 변환해준다.

이후, 다음과 같이 움직인 거리만큼 업데이트를 하고, 이들을 최솟값과 최댓값으로 바운드처리를 해준다.

func updatedLowerValue(moved delta: Double) -> Double {
  return (lowerValue + delta).bound(lower: minimumValue, upper: upperValue - gapBetweenSliders)
}

func updatedUpperValue(moved delta: Double) -> Double {
  return (upperValue + delta).bound(lower: lowerValue + gapBetweenSliders, upper: maximumValue)
}

초 단위를 View의 좌표계로 변경

다음으로 이 lowerValue, upperValue를 가지고 실제 View에서의 위치를 표기해야 한다.

실제 imageFrame이 위치하는 곳은 파란색 부분이다. 하지만, SliderThumb는 ImageFrame보다 바깥쪽에서 움직일 수 있게 된다.

즉, 위와 같이 왼쪽 기준을 각각의 value가 위치하는 곳이라 치면,

2개의 Slider가 맞닿으면, 실제로 SliderThumb의 넓이만큼의 초가 남아있게 된다.

func updateSliderFrame(_ slider: EditSlider) {
  let width = Constants.sliderWidth
  
  let leading = slider === lowerSlider ? leading(of: lowerValue) : leading(of: upperValue)
  
  slider.frame = CGRect(
    x: leading,
    y: 0,
    width: width,
    height: bounds.height
  )
  updateTopAndBottomLayer()
}

func leading(of value: Double) -> Double {
  return totalLength * value / maximumValue // totalLength는 움직일 수 있는 실제 거리
}

위의 코드로 실제 view의 frame에 매핑을 해주면 된다.

영상 위치 조절 기능

다음으로는 영상 위치를 나타내는 seekThumb를 구현해보자.

private let seekThumb = SliderThumb(tintColor: .white, hightlightedColor: .systemGray4)

마찬가지로 seekValue를 초단위이다.

private(set) var seekValue: Double = 0 {
  didSet {
    updateSeekThumbFrame()
    delegate?.seekValueDidChanged(self, value: seekValue)
  }
}

위치 계산

View의 좌표계에서 초 단위로 변환

lowerThumb, upperThumb와 마찬가지로, Devide상에서의 위치 변화를 초단위인 seekValue로 변환해주어야 한다.

override func continueTracking(_ touch: UITouch, with event: UIEvent?) -> Bool {
  ...

  let seekThumbDeltaValue = deltaValue(from: previousLocation, to: location)
  
  if thumb === seekThumb {
    self.seekValue = updatedSeekValue(moved: seekThumbDeltaValue)
  }
  ...
  
  sendActions(for: .valueChanged)
  return true
}

func updatedSeekValue(moved delta: Double) -> Double {
  return (seekValue + delta).bound(lower: lowerValue, upper: upperValue)
}

이때 주의할점은 seekValue의 경우에는 bound가 lowerValue서부터, upperValue까지이다.

초 단위를 view의 좌표계으로 변환

마지막으로 seekValue를 view의 좌표값 단위로 변경해주어야 한다.

이때 주의 할점은 seekThumb와 lowerThumb, upperThumb의 움직일 수 있는 범위가 다르다는 것이다.

따라서, seekThumb의 leading을 구해주는 코드는 lowerValue로부터 떨어져 있는 값을 실제 Device에서의 위치로 변환을 해주면 된다.

func leadingForSeek(of value: Double) -> Double {
  let range = upperValue - lowerValue
  guard range > 0 else { return 0 }
  
  let proportion = (value - lowerValue) / range
  return Double(upperThumb.frame.minX - lowerThumb.frame.maxX) * proportion
}

Frame이미지 생성

마지막으로 ImageFrame을 생성하는 코드이다.

이때, 처음으로 생각했던 방법은 다음과 같이 ImageView를 Frame 갯수만큼 생성해주어,

이미지를 넣어주는 방식이다.

하지만, Frame 갯수만큼 ImageView가 생성되기 때문에, 최적화를 위해

각 Frame의 이미지를 하나로 합치기로 결정했다.

func frameImage(
  with generator: AVAssetImageGenerator,
  times: [CMTime],
  frameWidth: CGFloat
) async -> UIImage {
  var resultImages = Array(repeating: UIImage(), count: Constants.frameCount)
  
  await withTaskGroup(of: Void.self) { group in
    for (index, time) in times.enumerated() {
      group.addTask {
        guard let image = try? await generator.generateUIImage(at: time) else { return }
        resultImages[index] = image
      }
    }
  }
  // 이미지를 하나로 합치기
}

우선, frame 갯수에 맞는 이미지들을 ~~AVAssetImageGenerator~~를 통해 이를 생성한다.

마지막으로 이미지를 하나로 합쳐줘야 한다.

이때, 합치는 방법에는 크게 CPU기반과 GPU기반이 있다.

둘의 시간 측정을 하기 위해서 영상길이를 4분 4초이고, frame 갯수는 500개로 설정했다.

CPU 기반 랜더링

extension Array where Element: UIImage {
  func concatImagesHorizontaly() -> UIImage {
    let maxWidth = self.compactMap { $0.size.width }.max()
    let maxHeight = self.compactMap { $0.size.height }.max()
    
    let maxSize = CGSize(width: maxWidth ?? 0, height: maxHeight ?? 0)
    let totalSize = CGSize(width: maxSize.width * (CGFloat)(self.count), height: maxSize.height)
    
    return UIGraphicsImageRenderer(size: totalSize).image { context in
      for (index, image) in self.enumerated() {
        
        let rect = CGRect(
          x: maxSize.width * CGFloat(index),
          y: 0,
          width: maxSize.width,
          height: maxSize.height
        )
        
        image.draw(in: rect)
      }
    }
  }
}

위와 같은 CPU기반 랜더링 방식에선, 7초가 소요되었다.

GPU 기반 랜더링

extension Array where Element: UIImage {
  func concatImagesHorizontallyGPU() -> UIImage {
    let context = CIContext(options: [CIContextOption.useSoftwareRenderer: false])

    let ciImages = self.compactMap { CIImage(image: $0) }

    guard !ciImages.isEmpty else { return UIImage() }

    let maxWidth = ciImages.compactMap { $0.extent.width }.max() ?? 0
    let maxHeight = ciImages.compactMap { $0.extent.height }.max() ?? 0
    
    let maxSize = CGSize(width: maxWidth, height: maxHeight)
    let totalSize = CGSize(
      width: maxSize.width * (CGFloat)(self.count),
      height: maxSize.height
    )
    let finalRect = CGRect(origin: .zero, size: totalSize)
    
    let outputImage = ciImages.enumerated().reduce(CIImage()) { result,  element in
      let (index, image) = element
      let xOffset = maxWidth * CGFloat(index)
      
      let translatedImage = image.transformed(by: CGAffineTransform(
          translationX: xOffset,
          y: (maxHeight - image.extent.height) / 2
        )
      )
      return result.composited(over: translatedImage)
    }
    
    // 결과를 UIImage로 변환
    guard let cgImage = context.createCGImage(outputImage, from: finalRect) else { return UIImage() }
    return UIImage(cgImage: cgImage)
  }
}

위와 같은 GPU 랜더링 방식에선, 동일한 조건에서 0.3초가 소요됐다.

이미지 블러 처리

마지막으로 이미지의 블러처리이다.

아래 사진과 같이 lowerThumb와 upperThumb밖에 있는 영역에 있는 이미지는 위와 같이 Blur처리를 해주어야 한다.

이를 처리 하기 위해서, VideoTrimmingSliderBar 최상단에 BlurView를 하나 추가했다.

해당 BlurView는 다음과 같이 된다.

final class ImageFrameBlurView: UIView {
	var selectedRect: CGRect = .zero {
		didSet { setNeedsDisplay() }
	}
	
	init() {
		super.init(frame: .zero)
		self.backgroundColor = .clear
	}
	
	override func draw(_ rect: CGRect) {
		super.draw(rect)
		guard let context = UIGraphicsGetCurrentContext() else { return }
		
		context.setFillColor(UIColor.black.withAlphaComponent(0.4).cgColor)
		context.fill(self.bounds)
		
		context.setBlendMode(.clear)
		context.fill(selectedRect)
		
		context.setBlendMode(.normal)
	}
	...
}

즉, selectedRect 외의 영역은 blur처리로 fill을 해주고, 외의 영역을 clear로 처리했다.

[Algorithm] 그래프 탐색 알고리즘 - BFS & DFS

seok-young — Fri, 16 Aug 2024 11:31:05 +0900

"그래프 탐색"이란 그래프에서 하나의 노드를 시작으로 다수의 노드를 방문하는 알고리즘을 말한다.

이때, 방문하는 노드는 딱 한 번씩만 방문하는 것이 특징이다.

만약, 자료구조 그래프에 대한 내용이 궁금하다면 아래 포스팅을 참고 바란다.

https://seokyoungg.tistory.com/94

[Data Structure] Graph

"그래프"(Graph)는 각 데이터와 그들을 잇는 선들로 이루어진 ADT이다. 각 데이터들을 "정점"(vertex) 혹은 "노드"(node)라 부르며, 이들을 잇는 선을 "간선"(edge)라 부른다. 즉, 그래프는 유한한 개수의

seokyoungg.tistory.com

이러한 그래프 탐색 알고리즘에는 2가지가 있다.

BFS
DFS

BFS

"BFS"는 Breadth-first Search의 약자로 말 그대로 너비 우선 탐색이다.

BFS는 하나의 정점을 시작으로 인접한 모든 정점들을 우선 방문하는 방법이다.

이때, BFS는 자료구조 Queue를 사용하게 된다.

만약, 자료구조 Queue에 대한 설명과 구현방법이 궁금하다면, 해당 포스팅을 참고 바란다.

https://seokyoungg.tistory.com/90

[Data Structure] Queue

"큐"(Queue)는 선형 자료구조로 2가지 Main Operation을 기본적으로 제공하는 ADT이다. enqueue(push) : 원소를 추가한다. dequeue(pop) : 가장 처음에 추가된 원소를 제거한다. 지난 포스팅에서 다루었던 스택은

seokyoungg.tistory.com

구현

그래프를 구현하는 방법에는 크게 2가지가 있다.

인접 행렬
인접 리스트

이 2가지 방식별로 코드와 시간복잡도는 달라지게 된다.

인접 행렬

func bfs<T>(graph: AdjacencyMatrixGraph<T>, startNode: Node<T>) {
	var queue = Queue<Node<T>>()
	var isVis = [Node<T>: Bool]()
	
	isVis[startNode] = true
	queue.enqueue(startNode)
	
	while let current = queue.dequeue() {
		// 모든 vertex와 연결되어 있는지 정보를 확인한다.
		let allVertexs = graph.allVertexs()
		for vertex in allVertexs {
			if !graph.isConnect(from: current, to: vertex) { continue }
			if isVis[vertex] != nil { continue }
			
			isVis[vertex] = true
			queue.enqueue(vertex)
		}
	}
}

우선, 앞서 말했듯 Queue자료구조와 방문했는지 여부를 확인하기 위한 ~~isVis~~ 배열도 선언한다.

이후 과정은 다음과 같다.

초기 지점을 Queue에 넣어주고, ~~isVis~~를 통해 방문 여부를 체크해 준다.
이후, 아래 과정을 Queue가 비어 있을 때까지 반복한다.
graph내의 모든 정점들에 대해, 현재 정점과 연결되어 있는지 확인한다.
만약 연결되어 있고, 방문 이력이 없다면 방문한다.
방문할 땐, 큐에 넣어주고 ~~isVis~~를 true로 체크해준다.

인접 리스트

func bfs<T>(graph: AdjacencyListGraph<T>, startNode: Node<T>) {
	var queue = Queue<Node<T>>()
	var isVis = [Node<T>: Bool]()
	
	isVis[startNode] = true
	queue.enqueue(startNode)
	
	while let current = queue.dequeue() {
		// 현재 노드를 기준으로 인접 노드만 확인한다.
		for vertex in graph.adjacentVertex(for: current) {
			if isVis[vertex] != nil { continue }
			
			isVis[vertex] = true
			queue.enqueue(vertex)
		}
	}
}

전체적인 과정은 인접행렬과 유사하다.

하지만, 모든 노드에 대해 연결된 노드를 직접 찾아야 했다면,

인접 리스트는 연결된 노드에 바로 접근할 수 있다.

시간복잡도

정점의 개수가 $ V$, 간선의 갯수가 $E$라고 가정해 보자.

인접 행렬

인접행렬의 경우, 현재 노드에 대해 모든 노드와 연결되어 있는지 확인 후 방문을 진행했다.

따라서, $O(V^2)$의 시간복잡도가 소요된다.

인접 리스트

인접 리스트의 경우, 현재 노드에 대해 연결된 노드의 개수만큼 확인 후 방문하게 된다.

즉, 모든 노드를 돌게 되며 ($V$번), 이때 그래프 내의 모든 간선의 개수만큼 확인하게 된다. $E$

따라서 시간복잡도는 $O(V + E)$가 된다.

인접 행렬 vs. 인접 리스트

간선의 수가 적은 Sparse Graph의 경우에는 메모리적인 측면에서도 시간복잡도 측면에서도 인접리스트가 유리하다.

반면, 간선이 많은 그래프(Dense Graph)에선 인접행렬을 사용하는 것이 유리하다.

활용 사례

최단 거리 문제

가장 대표적으로 최단 경로 문제를 해결할 수 있다.

다만, 간선의 가중치가 모두 동일해야 한다.

가중치가 다른 경우의 최단 거리는 "다익스트라", "벨만 포드"등등 다른 알고리즘을 통해 해결해야 한다.

BFS는 너비 우선 탐색이다. 따라서, 목적지까지 가장 먼저 도착한 경로가 최단 거리가 된다.

따라서, 다음과 같이 ~~isVis~~를 통해 거리를 확인해 주면 된다.

(백준 문제의 경우, 대부분 BFS문제에서 2차원 배열을 graph로 활용하기 때문에, graph를 2차원 배열로 변경했다.)

func bfs<T>(graph: [[T]], startPoint: Point, endPoint: Point) -> Int {
	var queue = Queue<Point>()
	var isVis = Array(
		repeating: Array(repeating: 0, count: graph[0].count),
		count: graph.count
	)
	
	isVis[startPoint.x][startPoint.y] = 0
	queue.enqueue(startPoint)
	
	while let current = queue.dequeue() {
		let currentDistance = isVis[current.x][current.y]
		
		if current == endPoint {
			return currentDistance
		}
		
		for direction in (0..<4) {
			let nextX = current.x + disX[direction]
			let nextY = current.y + disY[direction]
			
			if nextX < 0 || nextX >= graph.count || nextY < 0 || nextY >= graph[0].count { continue }
			if isVis[nextX][nextY] != 0 { continue }
			
			isVis[nextX][nextY] = currentDistance + 1
			queue.enqueue(.init(x: nextX, y: nextY))
		}
	}
	
	return -1
}

이외에도 웹 크롤링, 그래프 연결성 검사 등등 다양한 분야에서 활용된다.

DFS

"DFS"는 Depth- First Search의 약자로 깊이 우선 탐색이다.

"DFS"는 하나의 노드를 시작해서 다음 분기로 넘어가기 전에 해당 분기를 완벽하게 탐색하는 방식이다.

BFS와의 탐색 과정 차이를 보게 되면 다음과 같다.

이러한 DFS에서는 스택 자료구조를 사용하게 되는데, 스택에 대한 자세한 설명은 아래 링크를 참고 바란다.

https://seokyoungg.tistory.com/89

[Data Structure] Stack

"스택"(Stack)은 말 그대로 "무언가를 쌓아 올린 것"을 의미한다.대표적으로 프링글스 통이 있다. 프링글스 통 안에는 과자가 쌓여있고, 최근에 들어간 과자가 가장 먼저 나오는 구조이다. 이러한

seokyoungg.tistory.com

이러한 DFS는 재귀로도 해결할 수 있다.

사실, 재귀함수의 호출 형태가 내부적으로는 Stack자료구조에 해당 함수의 Stack Frame을 쌓는 구조이기 때문에, 유사하다.

구현

BFS와 마찬가지로 인접 행렬, 인접리스트 둘 다 활용이 가능하다.

또한, 앞서 말했듯 재귀 스택 둘다 활용이 가능하다.

인접 행렬

우선, Stack의 방식이다.

func dfsStack<T>(graph: AdjacencyMatrixGraph<T>, startNode: Node<T>) {
	var stack = Stack<Node<T>>()
	var isVis = [Node<T>: Bool]()
	
	while let current = stack.pop() {
		let allVertexs = graph.allVertexs()
		for vertex in allVertexs {
			if !graph.isConnect(from: current, to: vertex) { continue }
			if isVis[vertex] != nil { continue }
			
			isVis[vertex] = true
			stack.push(vertex)
		}
	}
}

코드를 보게 되면, BFS와 유사하다. 다만, 차이점은 Stack과 Queue의 자료구조의 차이점에 있다.

다음으로는 재귀호출의 방식이다.

func dfsReculsive<T>(
	graph: AdjacencyMatrixGraph<T>,
	currentNode: Node<T>,
	isVis: [Node<T>: Bool]
) {
	guard isVis[currentNode] == nil else { return }
	var isVis = isVis
	isVis[currentNode] = true
	
	for vertex in graph.allVertexs() {
		if !graph.isConnect(from: currentNode, to: vertex) { continue }

		dfsReculsive(graph: graph, currentNode: vertex, isVis: isVis )
	}
	isVis[currentNode] = false
}

재귀 호출 방식도 상당히 유사하다. 다만 Stack 내부에서 구현했던 코드를 붙여 넣은 게 전부이다.

인접 리스트

우선, stack의 구현방식이다.

func dfsStack<T>(graph: AdjacencyListGraph<T>, startNode: Node<T>) {
	var stack = Stack<Node<T>>()
	var isVis = [Node<T>: Bool]()
	
	while let current = stack.pop() {
		for vertex in graph.adjacentVertex(for: current) {
			if isVis[vertex] != nil { continue }
			
			isVis[vertex] = true
			stack.push(vertex)
		}
	}
}

마찬가지로 BFS의 방식가 유사하나 사용한 자료구조가 Queue가 아닌 Stack이라는 차이점이 있다.

다음으로 재귀방식이다.

func dfsReculsive<T>(
	graph: AdjacencyListGraph<T>,
	currentNode: Node<T>,
	isVis: [Node<T>: Bool]
) {
	guard isVis[currentNode] == nil else { return }
	var isVis = isVis
	
	isVis[currentNode] = true
	
	for vertex in graph.adjacentVertex(for: currentNode) {
		dfsReculsive(graph: graph, currentNode: vertex, isVis: isVis )

	}
	
	isVis[currentNode] = false
}

시간복잡도

DFS 역시 마찬가지로 시간복잡도가 동일하다.

인접 행렬: $O(V^2)$
인접 리스트: $O(V + E)$

하지만, DFS를 재귀로 구현하는 경우, Address Space의 Stack 메모리가 다 차게 되는 Stack OverFlow가 발생할 수 있다.

활용 사례

BFS와 마찬가지로 최단거리 탐색에 사용될 수 있지만, BFS와 다른 점은 다음과 같다.

BFS에선 최초로 목적지에 도달한 지점이 최단거리임을 보장했지만, DFS에선 보장하지 않는다.

이는 깊이 우선 탐색이기 때문이며, 이를 위해 별도의 길이를 저장하는 전역변수 혹은 파라미터 필요하게 된다.

따라서, 최단 거리 문제에선 BFS가 대부분 유리하다.

이 외에, 백트레킹, 그래프의 사이클 찾기 등등 여러 분야에서 사용된다.

References

위키백과

Breadth-first search

Depth-first search

[Algorithm] 정렬 알고리즘(2) - 머지 소트, 퀵 소트, 기수 정렬

seok-young — Mon, 12 Aug 2024 16:12:01 +0900

이전 포스팅에서 살펴본 정렬 알고리즘들은 평균, 최악의 경우 $O(n^2)$의 시간복잡도를 가지게 되었다.

병합 정렬 (Merage Sort)

"병합 정렬"(또는 합병 정렬)은 문제를 분할하고, 문제를 정복하여 합치는 분할정복을 기반으로 한 정렬 알고리즘이다.

정렬 과정

이러한 분할정복은 "하향식"과 "상향식"구현으로 구분할 수 있는데,

병합 정렬에선 하향식 구현방식을 대부분 사용한다.

하향식(TopDown)방식으로 구현한 병합 정렬의 과정은 다음과 같다.

(아래 그림은 정확한 Top-Down 방식은 아니지만, 분할되고 정복되는 순서만 차이 있을 뿐, 방법은 동일하다.)

리스트를 절반으로 나누어 두 부분 리스트로 나눈다.
이를 부분 리스트의 길이가 1이하가 될 때까지 재귀적으로 위의 과정을 반복한다. (길이가 1인 부분리스트는 정렬되었다고 볼 수 있다.)
이후, 정렬된 두 부분리스트를 합칠 때, "임시 저장공간"에 정렬된 결과를 저장한다.
이후, 원본 리스트에 정렬 결과를 복사한다.

시간 복잡도 증명

"분할 정복"의 시간복잡도는 최선, 최악, 평균의 경우 모두 $O(n \cdot logn)$을 갖는다.

왜 $O(n \cdot logn)$알아보기 위해, 각 분할 과정과 정복 과정을 따로따로 살펴보자.

분할 과정

입력의 갯수가 $n$이라고 가정해 보자.

각 총 $k$라 가정하고 Depth별로 분할 횟수를 살펴보면, 위에서부터 순차적으로

$1, 2, 4, 8, ..., 2^k$회씩 분할한다.

이때, Depth는 $log(n)$ 이므로 $k = log(n)$이다.

또한, 이때 지수 로그 공식에 따라 $2^{logn} = n$으로 대체가 가능하다.

따라서 최종적으로 $1, 2, 4, 8, ..., n$회씩 분할한다.

이때, 각 분할작업에 들어가는 시간복잡도는 입력에 비례하지 않기에 상수시간이라 볼 수 있다.

즉, $T(n) = c(1 + 2 + 4 + .. + n) = c(2n - 1) = O(n)$이 된다.

정복 과정

각 Depth마다 모든 원소를 비교하면서 병합을 진행한다.

앞서 말했듯, Depth는 총 $log(n)$이며, 각 Depth마다 총 $n$개의 원소를 비교하는 작업을 진행한다.

따라서, $O(n \cdot logn)$이다.

이때, 분할 과정과 정복과정은 독립적으로 수행되기 때문에, 둘의 시간복잡도는 곱이 아닌 합연산이다.

$O(n \cdot logn + n)$이게 되고, 점근적 표기에서 최고차항 외에는 생략하므로,

최종적으로 병합 정렬은 $O(n \cdot logn)$의 시간복잡도를 갖는다.

수식적으로 증명

$T(n)$을 n개의 원소를 분할 정복할 때의 시간복잡도라고 가정해 보자.

이때, 앞서 말했듯 분할 정복 기법이기 때문에 2개의 부분 리스트로 분할하며,

합칠 때는 총 $n$개의 원소를 비교하기 때문에, $n$의 시간복잡도가 든다.

따라서,$T(n) = 2 \cdot T(n/2) + n$ 으로 볼 수 있다.

$T(n) = 2(2 \cdot T(n/4) + n/2) + n = 4 \cdot T(n/4) + 2n$

$T(n) = n \cdot T(1) + n \cdot logn$

$T(1) = 1$이므로, $T(n) = n + n \cdot logn$ 이 완성된다.

이때, $g(n) = n \cdot logn$이라 가정할 때, $n_0 \geq 10$이고 $c =2$일 때,

$n \geq n_0$인 모든 자연수에 대하여 $g(n) \geq T(n)$을 만족한다.

점근적 상한의 정의에 의해 $T(n) = O(n \cdot logn)$가 된다.

특징

제자리 정렬 X
안정 정렬
시간복잡도가 $O(n \cdot logn)$

병합 정렬은 앞서 살펴봤다시피, 병합하는 과정에서 새로운 메모리 공간에 병합을 하고, 이를 원본 메모리에 복사한다.

즉, 추가적인 메모리가 필요하기 때문에 제자리 정렬이 아니다.

구현

extension Array where Element: Comparable {
	func mergeSort(
		sortedBy: (Element, Element) -> Bool = { $0 < $1 }
	) -> [Element] {
		return mergeSort(self, st: 0, en: self.count, sortedBy: sortedBy)
	}
	
	private func mergeSort(
		_ array: [Element],
		st: Int,
		en: Int,
		sortedBy: (Element, Element) -> Bool
	) -> [Element] {
		guard st < en - 1 else { return array }

		let mid = (st + en) / 2
		var array = array
		
		array = mergeSort(array, st: st, en: mid, sortedBy: sortedBy)
		array = mergeSort(array, st: mid, en: en, sortedBy: sortedBy)
		
		return merge(array, st: st, en: en, sortedBy: sortedBy)
	}
	
	private func merge(
		_ array: [Element],
		st: Int,
		en: Int,
		sortedBy: (Element, Element) -> Bool
	) -> [Element] {
		var array = array
		
		let mid = (st + en) / 2
		var index1 = st
		var index2 = mid
		
		var temp = [Element]()
		
		for _ in st..<en {
			if index1 == mid {
				temp.append(array[index2])
				index2 += 1
			} else if index2 == en {
				temp.append(array[index1])
				index1 += 1
			} else if sortedBy(array[index1], array[index2]) {
				temp.append(array[index1])
				index1 += 1
			} else {
				temp.append(array[index2])
				index2 += 1
			}
		}
		
		for i in 0..<temp.count {
			array[i + st] = temp[i]
		}
		
		return array
	}
}

퀵 정렬

"퀵 정렬"은 제자리 정렬 알고리즘으로,

분할 정복을 기반으로 수행되며 매우 빠른 속도를 자랑한다.

분할 정복을 기반으로 한다는 점에서 병합 정렬과 유사해 보이지만,

퀵정렬은 제자리 정렬 알고리즘이란 차이점이 있다.

이전 포스팅에서 말했지만,

"제자리 정렬"은 추가적인 메모리 공간의 할당을 필요로 하지 않기 때문에,

공간 지역성(Spatical Locality)에 Cache Hit비율이 높아, 좋은 성능을 자랑한다.

정렬 과정

"퀵 정렬"은 분할 정복을 통해 리스트를 정렬한다.

리스트에서 하나의 원소를 선택한다. 이 원소를 "피벗"이라 부른다.
현재 리스트를 순회하면서, 피벗보다 작은 원소는 피벗 앞으로, 피벗보다 큰 원소는 피벗 뒤로 위치시킨다.
위의 과정으로 "피벗의 위치"가 결정 나므로, 피벗을 기준으로 리스트를 둘로 분할하여 위의 과정을 반복한다.
해당 과정을 재귀적으로 반복하여, 리스트의 크기가 0 혹은 1이 될 때까지 반복한다.

매 재귀 호출이 이뤄질 때마다, 피벗의 위치가 결정 난다.

즉, 최소한 하나의 원소의 위치가 결정 나게 되기 때문에, 재귀 호출은 반드시 끝난다는 것을 보증할 수 있으며, 최종적으로는 정렬된다는 것을 알 수 있다.

시간 복잡도 증명

퀵소트에서 $n$개의 원소를 정렬한다고 가정해 보자.

선택된 피벗의 위치가 $m$번째 원소라고 가정했을 때, (단, $m$은 n 이하의 자연수)

정렬과정을 수행 후, $m-1$과 $n-m$개의 원소로 분할되어 재귀적으로 반복한다.

이때, 피벗에 대하여 피벗을 비교하는 연산과 Swap 하는 연산이 이루어지는데,

해당 연산을 $C(n)$이라 가정했을 때, $\Theta(n)$이라 할 수 있다.

(둘은 독립적으로 수행되며 모두 n에 비례하기 때문에 가능하다.)

즉, 퀵소트의 시간복잡도는 다음과 같이 표기할 수 있다.

$T(n) = T(m-1) + T(n-m) + \Theta(n)$ $\leq T(m-1) + T(n-m) + c \cdot n$

$c \geq 3$일때 위의 식은 성립한다.

최악의 경우 (Worst Case)

최악의 경우에는 피봇이 맨 앞의 원소 혹은 맨 뒤의 원소를 선택할 경우이다.

해당 경우에는 균등하게 분할되지 않아 $O(n^2)$의 시간복잡도를 갖게 된다.

즉, 위의 식에서 $m = 1$이거나$m = n$인 경우이다.

이때, $T(0) = 0$ 이므로, 다음과 같이 표기할 수 있다.

이때, 이를 반복적으로 해보게 되면,

측 $T(n) \leq c\cdot n^2$가 성립하므로

$T(n) = O(n^2)$이다.

최선의 경우 (Best Case)

최선의 경우에는 피봇이 항상 균등하게 분할하는 경우이기에, 다음과 같은 식이 성립한다.

이때, $n/2$에 대해서 진행해보면 다음과 같다.

이를 좀 더 일반화해보게 되면 다음과 같다.

이를 통해 위의 수식을 일반화하게 되면 다음과 같다.

이때 $k = logn$이므로, 지수 로그 법칙에 의해 $2^k = n$이 성립한다. 따라서 위의 식은 최종적으로 다음과 같이 성립한다.

따라서, 최종적으로 $T(n) = O(n \cdot logn)$이 성립하게 된다.

평균의 경우 (Average Case)

이때, 피봇을 랜덤하게 선택한다고, 가정했을 때, 각 원소들이 피봇이 될 확률을 $\frac{1}{n}$이다.

즉, 기댓값을 적용하여 위의 식은 아래와 같이 정의할 수 있다.

이때, $\sum_{m=1}^{n}T(m-1) = \sum_{m=1}^{n}T(n-m)$이기 때문에 아래와 같이 표현할 수 있다.

이때, 양변에 $n$을 곱해주게 되면 다음과 같은 수식을 얻게 된다.

($n$은 자연수이기 때문에 부등호의 방향은 바뀌지 않는다)

이때 $n = n-1$을 대입해 보게 되면, 다음과 같은 식을 얻게 된다.

이때 (A)-(B)를 하게 되면, 다음과 같은 식을 얻게 된다.

양 변의 항들을 다음게 되면 최종적으로 다음과 같은 식을 얻게 된다.

이때, 항상 $T(n) \geq T(n-1)$이 성립하기 때문에, 다음과 같이 식을 변경할 수 있다.

즉, 최종적으로 다음과 같은 식을 얻게 된다.

이 때, 양 변을 $frac{1}{n(n+1)}$로 나누게 되면 다음과 같은 식을 얻는다.

해당 식에서 $n = n-1$을 대입하게 되면 다음과 같은 식을 얻게 된다.

해당식의 결과를 위의 식의 $\frac{T(n-1)}{n}$ 대입하게 되면 다음과 같은 결과를 갖는다.

위에서 대입하던 과정을 $T(n-2), T(n-3), ... T(1)$까지 반복하게 되면 최종적으로 다음과 같은 식을 얻게 된다.

이를 정리해 보게 되면 다음과 같다.

이때, 다음과 같은 식이 성립한다.

따라서 최종적으로 다음과 같은 식을 도출해낼 수 있다.

이때, 양변을 다시 $n+1$로 곱하게 되면, 다음과 같다.

마지막으로, 빅-오 점근 표기법 공식에 따라 $T(n) = O(n \cdot log_2n)$의 시간복잡도를 갖는다.

특징

퀵정렬은 다음과 같은 성격을 갖는다.

최악의 경우 $O(n^2)$, 최선, 평균의 경우는 $O(n \cdot logn)$의 시간복잡도를 갖는다.
제자리 정렬이기에 속도적으로 이점이 있다.
불안정 정렬에 속한다.

즉, 퀵 정렬에선 피봇을 어떻게 선택하냐가 성능에서 많은 부분을 차지한다.

우선적으로 맨 앞의 원소를 피벗으로 두는 방법도 있고, 랜덤 하게 선택하는 방법도 있다.

또한, 3개의 피벗 후보를 선택해 그중, 중앙값을 선택하는 방법을 사용하기도 한다.

실제로 1대 99 비율로 계속 쪼개지더라고 시간 복잡도를 $O(n \cdot logn)$이다.

구현

// MARK: - QuickSort
extension Array where Element: Comparable {
	enum PivotType {
		case random
		case first
		case middle // 랜덤으로 선택된 3개의 값들 중 중앙값
	}
	
	func quickSort(
		sortedBy: (Element, Element) -> Bool
	) -> [Element] {
		guard
			self.count > 1,
			let pivot = self.pivot(.random)
		else { return self }
		
		let left = self.filter { sortedBy($0, pivot) }
		var right = self.filter { !sortedBy($0, pivot) }
		if let firstIndex = right.firstIndex(of: pivot) {
			right.remove(at: firstIndex)
		}
		
		
		let sortedLeft = left.quickSort(sortedBy: sortedBy)
		let sortedRight = right.quickSort(sortedBy: sortedBy)
		
		return sortedLeft + [pivot] + sortedRight
	}
	
	private func pivot(_ type: PivotType) -> Element? {
		switch type {
			case .first:
				return self.first
				
			case .random:
				return self.randomElement()
				
			case .middle:
				if let randoms = self.randomElements(count: 3) {
					return randoms.sorted()[1]
				} else {
					return self.first
				}
		}
	}
	
	private func randomElements(count: Int) -> [Element]? {
		guard self.count >= count else { return nil }
		
		var flags = Array<Bool>(repeating: false, count: self.count)
		var numbers = [Element]()
		
		while numbers.count != count {
			let randomIndex = Int.random(in: 0..<self.count)
			if !flags[randomIndex] {
				flags[randomIndex] = true
				numbers.append(self[randomIndex])
			}
		}
		
		return numbers
	}
}

기수 정렬

"기수 정렬"은 안정정렬로,

직접 수들을 비교하는 것이 아닌, 자릿수를 기준으로 정렬하는 알고리즘이다.

우선 정렬 로직은 다음과 같다.

1의 자릿수부터 시작해 각 자릿수에 숫자에 해당하는 Bucket에 숫자를 넣는다.
이후, Bucket에서 순차적으로 뺸 다면, 1의 자릿수의 정렬이 완료된다.
해당 과정을 10의 자리, 100의 자리 가장 높은 차수까지 진행한다.

실행 과정

다음과 같은 배열이 있다고 가정해 보자.

앞서, 자릿수를 기준으로 정렬한다 했기에 총 0~9까지 10개의 bucket이 필요하다.

우선 1의 자릿수별로 다음과 같이 buket에 담는다.

이때, Bucket에 담기는 숫자는 순서대로 진행한다. 따라서, 안정 정렬이다.

이제, 이를 순서대로 Bucket에서 빼내면서 1의 자릿수 정렬을 마친다.

다음으로 10 자릿수 정렬을 시작한다.

이후 마찬가지로, Bucket에서 빼내면서 10의 자릿수 정렬을 마친다.

마지막으로 100의 자릿수를 기준으로 정렬을 시작한다.

위와 같은 과정을 진행하게 되면 정렬이 완료되게 된다.

특징

우선 가장 큰 특징은 시간복잡도가 $O(w\cdot n)$이라는 것이다.

(n개의 숫자 중 가장 높은 차수를 w라고 가정)

즉, $w$가 작다면, 시간복잡도 측면에선 어떠한 알고리즘보다 빠르다.

하지만, 2141125....909등과 같이 차수가 매우 높은 숫자가 있다면, 해당 알고리즘의 시간복잡도는 $O(n^2)$에 수렴할 수도 있다.

따라서, 적절한 도메인에서는 빠른 수행시간을 자랑한다.

또한, 앞서 살펴봤듯 버킷이라는 추가적인 공간이 필요하게 된다.

구현

// MARK: - Radix Sort
extension Array where Element: BinaryInteger {
	func radixSort(
		sortedByAscending: Bool = true
	) -> [Element] {
		let radix = 10
		var done = false
		var index: Element = 1
		
		var returnArray = self
		
		while !done {
			done = true
			var buckets: [[Element]] = .init(repeating: [], count: radix)
			
			returnArray.forEach {
				let remainPart = $0 / index
				let digit = remainPart % Element(radix)
				let digitIndex = Int(digit)
				
				buckets[digitIndex].append($0)
				
				remainPart > 0 ? done = false : ()
			}

			sortedByAscending ? (returnArray = buckets.flatMap { $0 }) : (returnArray = buckets.reversed().flatMap { $0 })
			
			index *= Element(radix)
		}
		
		return returnArray
	}
}

References

위키백과

[Algorithm] 정렬 알고리즘(1) - 버블정렬, 선택정렬, 삽입정렬

seok-young — Wed, 10 Jul 2024 17:25:06 +0900

"정렬 알고리즘"은 일련의 원소들에 대해 정해진 규칙에 맞게 재배열하는 알고리즘이다.

정렬 알고리즘은 현대까지도 계속 발명 될 정도로, 많은 알고리즘이 존재하지만 이중 대표적으로 몇가지만 살펴볼것이다.

정렬 알고리즘 분류 기준

정렬 알고리즘은 여러 기준으로 분류된다.

안정 정렬 vs. 불안정 정렬

"안정 정렬"이란, 정렬조건이 동일한 원소가 여러개 있을 때, 입력 때와 동일한 순서로 정렬되는 정렬 알고리즘이다.

반면, "불안정 정렬" 입력 때와 동일한 순서로 졍렬되는 것을 보장하지 않는다.

"안정 정렬"은 정렬조건이 동일한 원소들의 순서를 보장해야할 때, 유용하게 사용될 수 있다.

예를 들어, 온라인 쇼핑몰에서 구매자의 구매 요청이 요청 순서대로 쌓인다고 가정해보자.

이때, 등급이 높은 회원부터 배송하기 위해서 등급순으로 정렬했을때,

불안정 정렬은 등급이 같은 회원일 경우, 먼저 구매했더라도 나중에 배송되는 상황이 발생할 수 있다.

이럴 경우 안정 정렬은 유용하게 사용될 수 있다.

제자리 정렬인지 아닌지

"제자리 정렬(In-place)" 추가적인 자료구조를 사용하지 않고 정렬이 가능한 정렬 알고리즘이다. 다만, 추가적인 변수를 위해 약간의 추가 공간은 허용한다.

제자리 정렬은 다음과 같은 장점을 갖는다.

우선, 추가적인 메모리 공간을 필요로하지 않는다는 점에서 메모리 측면으로 이득이 있다.

또한, 거의 모든 정렬 알고리즘은 배열을 자료구조로 사용하며, 배열은 메모리 공간에 연속적으로 할당되기 때문에, Cache hit 비율이 높다. 이러한 하나의 배열내에서 정렬알고리즘을 수행할 수 있다면, 공간 지역성에 의해 상대적으로 좋은 성능을 가지게 될 것이다.

버블 정렬

"버블 정렬"은 제자리 정렬로, 두 원소의 대소관계를 비교하여 위치를 변경을 반복하는 정렬 알고리즘이다.

또한, 인접한 원소와의 대소관계를 비교하기 때문에, 안정정렬이다.

자세한 절차는 다음과 같다.

extension Array where Element: Comparable {
	func bubbleSort(
		sortedBy: (Element, Element) -> Bool = { $0 < $1 }
	) -> [Element] {
		var sortedArray = self
		
		for i in (0..<self.count) {
			var isChanged = false
			
			for j in (0..<self.count-i-1) {
				if !sortedBy(sortedArray[j], sortedArray[j + 1]) {
					sortedArray.swapAt(j, j + 1)
					isChanged = true
				}
			}
			
			if !isChanged { break }
		}
		
		return sortedArray
	}
}

print([2, 5, 3, 1].bubbleSort()) // [1, 2, 3, 5]

1번째 원소부터 시작하여, 오른쪽의 원소와 대소관계를 비교한 후 필요하면 위치를 변경한다.
해당 과정을 n번째 원소까지 완료한다.
한번의 순회가 완료되면, 1번과정을 1부터 n-1번째 원소까지 반복한다.
이를 배열에 아무 변화가 없을때까지 반복한다.

위에서 볼 수 있겠지만, 2중 포문을 돌기 때문에 최악, 평균의 경우 모두 $O(n^2)$이다.

하지만, 모든 원소가 정렬되어 있다면 for문이 바로 종료되기 때문에, 최선의 경우 $O(n)$이다.

선택 정렬

"선택 정렬"은 제자리 정렬로, 다음과 같이 수행한다.

배열에서 제일 작은 원소를 탐색한다.
그 값을 맨앞에 위치한 값과 swap한다.
맨앞의 위치의 원소를 제외하고 위의 내용을 반복한다.

즉, 매 시행마다 앞자리가 하나씩 결정난다.

extension Array where Element: Comparable {
	func selectionSort(
		sortedBy: (Element, Element) -> Bool = { $0 < $1 }
	) -> [Element] {
		var sortedArray = self
		
		for i in 0..<self.count {
			
			var minIndex = i
			for j in i..<self.count {
				sortedBy(sortedArray[i], sortedArray[j]) ? () : (minIndex = j)
			}
			
			sortedArray.swapAt(i, minIndex)
		}
		
		return sortedArray
	}
}

print([2,3,1,4,7].selectionSort(sortedBy: <)) // [1, 2, 3, 4, 7]

위의 코드에서 볼 수 있겠지만, 선택 정렬은 최선, 최악, 평균의 경우 모두 $O(n^2)$이다.

빈번하게 swap연산이 있었던 버블정렬과 비교해보자면, 매 시행마다 딱 한번 swap연산이 일어나기 때문에, 일반적으로 버블정렬보다 성능이 좋다.

또한, 선택 정렬은 불안정정렬이다.

다음과 같은 원소들이 있다고 가정해보자.

(이때, 2와 2.은 같은 원소이고, 둘을 구분하기 위해 "!"을 붙였다.)

2 2! 1 3

우선, 1과 2의 위치가 변경되게 되면, 정렬은 종료된다.

1 2! 2 3

이때, 정렬전에는 2 2! 이었지만, 정렬후에는 2! 2로 순서가 변경되었다.

즉, 정렬 조건이 같은 원소에 대해 입력때와 동일한 순서를 보장하지 않는다.

삽입 정렬

"삽입 정렬"은 제자리 정렬로,

배열의 모든 요소를 앞에서부터 차례대로 이미 정렬된 부분과 비교하여, 자신의 위치를 찾아 삽입하는 정렬알고리즘이다.

즉, 다음과 같다.

2번째 원소부터 시작해, 1번째 원소와 비교해 삽입될 위치를 결정한다.
3번째 원소를 1, 2번째와 비교해 삽입될 위치를 결정한다.
이를 마지막 원소까지 진행하면된다.

extension Array where Element: Comparable {
	func insertionSort(
		sortedBy: (Element, Element) -> Bool = { $0 < $1 }
	) -> [Element] {
		guard self.count > 1 else { return self }
		var sortedArray = self
		
		for i in 1..<self.count {
			let key = sortedArray[i]
			
			var j = i-1
			// key값보다, 뒤로 밀어야 한다면 뒤로 밀고 남는 공간에 key를 삽입
			while j >= 0 && sortedBy(key, sortedArray[j]) {
				sortedArray[j+1] = sortedArray[j]
				j -= 1
			}
			sortedArray[j+1] = key
		}
		
		return sortedArray
	}
}

print([2,3,1,4,7].insertionSort(sortedBy: <)) // [1, 2, 3, 4, 7]

이러한 삽입 정렬은 안정 정렬이며,

다 정렬되어 있는 경우(최선의 경우) $O(n)$이고,

평균, 최악의 경우 $O(n^2)$이다.

또한, 버블 정렬과 선택 정렬과 비교했을 때 가장 성능이 좋은 정렬 알고리즘이다.

References

위키백과

[Algorithm] 알고리즘이란?

seok-young — Mon, 8 Jul 2024 13:00:18 +0900

수학 혹은 컴퓨터 과학(Computer Science)에서

"알고리즘"이란 어떠한 문제를 풀기 위한 "유한한 갯수의 일련의 시퀀스"이다.

이때, 알고리즘은 컴퓨터 프로그램으로 대부분 구현되나, 전기 회로 혹은 기계 등등 다른 수단으로도 구현될 수 있다.

특성

앞서 알고리즘을 "유한한 갯수의 일련의 시퀀스"라고 정의했지만, 여기서 몇가지 조건이 더 붙는다.

입력 : 잘 정의된 입력들을 받아들일 수 있어야 한다.
출력 : 정확성을 추론할 수 있는 출력이 있어야 한다.
명확성 : 각 단계는 명확하게 정의되어야 한다. 각 단계에서 수행할 작업을 정확하게 지정할 수 있어야 한다.
유한성 : 유한한 수의 명령어의 시퀀스가 수행되면 반드시 종료되어야 한다.
유효성 : 모든 명령어는 실행 가능해야 한다.

알고리즘 평가

"유한한 갯수의 시퀀스"가 몇달 혹은 몇년이 걸린다면 "효율적"으로 문제를 풀었다고 할 수 없다. 즉, 알고리즘은 효율성을 고려할 필요가 있으며, 이를 "복잡도"를 통해 평가할 수 있다.

"복잡도"는 시간과 공간을 얼마나 소모하는지를 중점으로 보는데, 이를 각각 시간 복잡도, 공간 복잡도라 부른다.

시간 복잡도

시간 복잡도는 "알고리즘의 소요시간을 측정"하는데 사용된다.

만약 다음과 같은 알고리즘 있다고 가정해보자.

int func(int arr[], int n) {
	int cnt = 0;
	
	for(int i = 0; i < n; i++) {
		if(arr[i] % 5 == 0) cnt ++;
	}
	
	return cnt;
}

해당 알고리즘의 시간을 측정하기에는 너무나 많은 변수가 있다.

컴퓨터마다 하드웨어 혹은 OS차이로 인한 실행시간의 차이가 있을 수가 있으며,

같은 컴퓨터라고 할지라도 매 순간 상태가 다르기 때문에, 같은 실행시간을 보장할 수 없다.

따라서, "시간 복잡도"는 문제를 해결하는데 걸리는 시간을 입력에 대한 연산횟수를 통해 나타낸다.

위의 명령어를 본다면, 시간 복잡도는 다음과 같다.

int cnt = 0; // 지역 변수 초기화: 1

우선, ~~cnt~~ 변수의 값을 0으로 선언하고 값을 넣는 과정에서 1번의 연산이 소요된다.

다음으로 for문은 수행하기 전에 i 변수를 초기화하는 연산을 1회 진행한다.

// i 초기화 연산: 1
for(int i = 0; i < n; i++) {
	// 매 iteration 시작 전 i < n 확인: 1
	
	// arr[i]가 5의 배수인지 비교: 2
	// cnt 증감 연산: 1
	if(arr[i] % 5 == 0) cnt ++;
	// 한번의 iteration이 끝난 후 i 증가: 1
}

이후, for문은 총 n번 반복하게 되는데, 다음과 같은 연산들을 반복한다.

매 iteration 시작 전 ~~i < n~~ 을 만족하는 지 확인하는 연산 1회
~~arr[i]~~를 5로 나누는 연산 1회
~~arr[i]~~를 5로 나누는 결과를 0과 비교하는 연산 1회
~~arr[i]~~가 5의 배수라면 ~~cnt~~를 증가시키는 연산 1회
매 iteration 완료 후, ~~i++~~ 하는 연산 1회

즉, 매 iteration마다 5회의 연산이 진행되며, iteration은 n번 반복하기 때문에 5n + 1번의 연산이 수행된다.

return cnt;

마지막으로 return 문제에서 1회 연산이 수행된다.

위의 연산은 n개의 입력에 대해 총 5n + 3번의 연산이 수행된다.

공간 복잡도

공간 복잡도는 "알고리즘이 사용하는 메모리 양을 측정"하는데 사용된다.

다음과 같은 문자열을 예시로 살펴보자.

var str = "12345"

8bit의 ASCII를 사용하는 언어에서는 해당 문자열을 널문자를 포함해 6byte로 특정할 수 있지만,

Swift와 같이 Unicode를 사용하는 언어에서는 UTF8이냐 UTF16이냐 등등 하나의 문자의 길이가 가변적이다.

즉, 언어마다 OS마다 변수하나를 저장하는데 사용하는 메모리양이 다를 수 있다.

따라서, 시간복잡도와 마찬가지로 "입력에 비례한 메모리 양"을 측정한다.

대다수의 경우 시간복잡도와 공간복잡도가 반비례한다.

과거와 달리, 현재 메모리값이 상당히 저렴하기 때문에 시간복잡도를 많은 경우에 우선적으로 고려한다.

점근 표기법

앞서 살펴본 시간복잡도와 공간복잡도는 "입력에 비레하여 측정"한다.

하지만, 모든 알고리즘마다 매번 이렇게 입력에 비례한 메모리양 혹은 연산횟수를 직접 세기에는 쉽지않다.

따라서, 이러한 시간복잡도와 공간복잡도를 표현할때는 점근 표기법을 사용한다.

"점근 표기법"은 어떤 함수의 증가 양상을 다른 함수와의 비교로 표현하는 방법이다.

정확히는 입력 n에 대해서 n을 무한대로 보냈을 때, 수렴하게 되는 새로운 함수로 표기하는 방법이다.

앞선 예시에서 5n + 3은 n을 무한대로 보내게 되면 n에 수렴하게 된다.

즉, 쉽게 말해 가장 영항력 있는 항으로 표기하는 방법이다.

이러한 점근 표기법에는 여러가지가 있지만, 알고리즘에서는 크게 3가지를 사용한다.

빅-오 표기법: 점근적 상한
빅-오메가 표기법: 점근적 하한
빅-세타 표기법: 점근적 평균

빅-오(Big-O) 표기법

"빅-오 표기법"은 점근적 상한에 대한 정의이며, 수학적인 정의는 다음과 같다.

$n_0 \leq n$인 모든 자연수 $n$에 대하여, $f(n) \leq c \cdot g(n)$를 만족하는 양의 상수 $c$와 $n_0$가 존재하면, $f(n) = O(g(n))$ 이다.

예시를 통해 살펴보자. $f(n) = 2n^4 + 3n^3 + n + 1$ 라고 가정해보자.

이때, $g(n) = n^4$이라면, $c \geq 3$일때, 기울기가 더 가파르기 때문에, 위의 조건을 만족하는 자연수 $n_0$은 존재한다.

따라서, $O(n^4)$으로 표기할 수 있다.

당연하게도 $O(n^5)$, $O(n^6)$, $O(2^n)$ 등등 가능하지만, 점근적 상한을 너무 높게 잡아버리게 되면 알고리즘의 성능을 파악하기 힘들기 때문에 가능한 가장 작은 점근적 상한을 잡는것이 좋다.

더욱 쉽게 말해, 적어도 해당 복잡도 안에 든다는 것을 의미한다.

빅-오메가(Big-$\Omega$)표기법

"빅-오메가 표기법"은 점근적 하한에 대한 정의이며, 수학적인 정의는 다음과 같다.

$n_0 \leq n$인 모든 자연수 $n$에 대하여, $f(n) \geq c \cdot g(n)$를 만족하는 양의 상수 $c$와 $n_0$가 존재하면, $f(n) = \Omega(g(n))$ 이다.

앞선 예시의 $f(n) = 2n^4 + 3n^3 + n + 1$를 다시 한번 살펴보자.

여기서, $g(n) = n^4$이라면, $c \leq 2$일때, 위의 조건을 만족하는 자연수 $n_0$는 존재한다.

따라서, $\Omega(n^4)$으로 표기할 수 있다.

마찬가지로 $\Omega(n^3)$, $\Omega(n)$, $\Omega(1)$ 등등 가능하지만, 점근적 하한을 너무 낮게 잡으면 성능을 파악하기 어려워진다.

쉽게 말해, 적어도 해당 복잡도보다는 크다는 것을 의미한다.

빅-세타(Big-$\Theta$)표기법

"빅-세타 표기법"은 점근적 평균에 대한 정의이며, 수학적인 정의는 다음과 같다.

$n_0 \leq n$인 모든 자연수 $n$에 대하여, $c_1 \cdot g(n) \leq f(n) \leq c_2 \cdot g(n)$를 만족하는 양의 상수 $c_1$, $c_2$와 $n_0$가 존재하면, $f(n) = \Theta(g(n))$ 이다.

마찬가지로 $f(n) = 2n^4 + 3n^3 + n + 1$를 예시로 들어보자.

여기서, $g(n) = n^4$이라면, $c_1 \leq 2$이고, $c_2 \geq 3$일때, 위의 조건을 만족하는 자연수 $n_0$는 존재한다.

따라서, $\Theta(n^4)$으로 표기할 수 있다.

평균적으로 해당 복잡도 안에 든다는 것을 의미한다.

빅-오, 빅-오메가, 빅-세타는 최악, 최선, 평균을 의미하지 않는다.

수많은 곳에서 빅-오는 최악의 경우, 빅-오메가는 최선의 경우, 빅-세타는 평균의 경우라고 정의하는 경우가 많다.

하지만, 이러한 해석은 틀린 해석이다.

다음과 같은 코드를 살펴보자.

func index(of target: Int, in array: [Int]) -> Int {
	for idx in (0..<array.count) {
		if arr[idx] == target { return idx }
	}
	
	return -1
}

앞서, 점근적 상한인 빅-오는 "적어도 이 복잡도 안에 든다는 것"을 의미한다고 했지만, 이때의 상한은 최악의 경우를 의미하지 않는다.

만약 ~~target~~이 1번째 인덱스에 존재하는 경우, 해당 함수는 1번만에 for문이 진행될것이다.

하지만, 최악의 경우 맨끝 인덱스에 존재하는 경우, ~~array~~의 원소 갯수 만큼 for문을 돌게 될것이다.

시간복잡도를 예시살펴보자면, 다음과 같이 최선, 최악의 경우 각기 다른 시간복잡도를 가지게 될 것이다.

즉, 복잡도를 논하기 위해서는 최선, 최악, 평균에 대한 시나리오부터 고려해야 한다.

빅-오 표기법은 "최선, 최악 혹은 평균의 경우 적어도 이 복잡도 안에 든다는 것"을 의미한다.

따라서, 위의 알고리즘은 최선의 경우 $O(1)$이고, 최악, 평균은 $O(n)$에 동작한다고 말할 수 있다.

다른 점근 표기법도 마찬가지로 이런 입력에 대한 시나리오부터 고려하는 것이 맞다.

대표적인 예시로 퀵소트 알고리즘의 경우, 최선, 평균의 경우 $O(n logn)$이며, 최악의 경우 $O(n^2)$으로 동작한다.

즉, 최선과 평균적인 입력에 대하여 적어도 $n logn$안에 동작하며, 최악의 경우에는 적어도 $n^2$안에 든다는 의미이지,

이를 $\Omega(n logn)$, $\Theta(n logn)$, $O(n^2)$으로 표기하지는 않는 이유이다.

Reference

위키백과

[PS] BOJ 2457 (공주님의 정원)

seok-young — Sun, 23 Jun 2024 22:26:40 +0900

문제부터 살펴보면 3월 1일부터 11월 30일까지 꽃이 지지 않게 하는 것이 핵심이다.

이때의 입력은 각각 꽃이 피는 날과 꽃이 지는 날이 들어온다.

1번째 접근

우선, 가장 먼저 생각나는 것은 특정 날짜 이전에 피는 꽃 중 가장 늦게 피는 꽃을 매 시행시 구하면 된다.

하지만, 매 시행 시 $N$개의 꽃을 살펴보게 되기 때문에, 시작 복잡도는 $O(N^2)$이 된다. 해당 문제에서 $N$은 최대 100,000이기 때문에, $O(N^2)$은 시간 초과가 발생하게 된다.

2번째 접근

매 시행시 특정 날짜 이전에 피는 꽃 중 가장 늦게 피는 꽃을 상수 혹은 로그 시간에 구할 수만 있게 된다면, 시간초과가 발생하지 않고 문제를 해결할 수 있게 된다.

이와 같이 그리디 한 풀이로 접근하면, 매 시행마다 꽃이 지는 날짜는 증가하게 될 것이다.

즉, 꽃이 지는 날짜는 다음 시행에서 선택할 꽃의 피는 날짜의 마지노선이기 때문에, 꽃이 피는 날짜를 기준으로 정렬을 해준다.

이때, 꽃이 지는 날짜를 기준으로 정렬하는 우선순위 큐에 선택할 수 있는 꽃을 삽입한 후,

매 시행시 우선순위 큐에서 원소를 빼내기만 하면 된다.

우선순위 큐에서 원소의 삽입, 삭제는 $O(logN)$이므로, 총 시간 복잡도는 $O(NlogN)$이 된다.

이를 코드로 옮겨보자면 다음과 같다.

풀이

우선, 스위프트에선 우선순위 큐를 제공하지 않아, 힙 자료구조부터 직접 구현해야 한다.

우선순위 큐구현에 관환 내용은 해당 포스팅을 참고 바란다.

https://seokyoungg.tistory.com/91

[Data Structure] Priority Queue

"우선순위 큐"(Priority Queue)는 다음과 같은 2개의 Main Operation을 명세하는 ADT이다.enqueue(push): 원소를 추가한다.dequeue(pop): 우선순위가 높은 원소를 제거한다. 지난 포스팅에서 다루었던 "큐"(Queue)

seokyoungg.tistory.com

// 시작날짜 기준으로 정렬
let sortedFlowers = flowers.sorted {
	$0.stDate < $1.stDate
}

다음과 같이 시작날짜 기준으로 정렬해 준 뒤,

while currentEnDate < targetEnDate {
	// 현재의 꽃이 지는날보다, 먼저 피는 꽃들을 우선순위 큐에 삽입한다.
	while
		flowerIndex < sortedFlowers.count &&
		sortedFlowers[flowerIndex].stDate <= currentEnDate {
		
		priorityQueue.push(sortedFlowers[flowerIndex])
		flowerIndex += 1
	}

	// 이후, 가장 늦게 지는 꽃을 선택한다.
	if let date = priorityQueue.pop() {
		currentEnDate = date.enDate
		result += 1
	} else {
		break
	}
}

매 시행마다, 선택 가능한 꽃들을 우선순위 큐에 삽입한 뒤, 가장 늦게 지는 꽃을 선택하면 된다.

전체 코드

Swift

import Foundation

struct Heap<T: Comparable> {
	enum HeapType {
		case min, max
	}
	
	private var nodes = [T]()
	private let sort: (T, T) -> Bool
	
	var isEmpty: Bool { nodes.isEmpty }
	var count: Int { nodes.count }
	var top: T? {
		guard !isEmpty else { return nil }
		return nodes[0]
	}
	
	init(type: HeapType) {
		switch type {
			case .min:
				sort = { $0 < $1 }
			case .max:
				sort = { $0 > $1 }
		}
	}
	
	mutating func insert(_ element: T) {
		nodes.append(element)
		shiftUp()
	}
	
	mutating func pop() -> T? {
		guard !isEmpty else { return nil }
		
		defer {
			nodes.swapAt(0, nodes.count - 1)
			nodes.removeLast()
			shiftDown()
		}
		
		return nodes[0]
	}
}

private extension Heap {
	mutating func shiftUp() {
		var now = nodes.count - 1
		var parent = getParent(of: now)
		
		while now > 0 && sort(nodes[now], nodes[parent]) {
			nodes.swapAt(now, parent)
			now = parent
			parent = getParent(of: now)
		}
	}
	
	mutating func shiftDown() {
		var now = 0
		
		while true {
			let (left, right) = getChilds(of: now)
			var candidate = now
			
			if left < nodes.count && sort(nodes[left], nodes[now]) {
				candidate = left
			}
			if right < nodes.count && sort(nodes[right], nodes[now]) && sort(nodes[right], nodes[left]) {
				candidate = right
			}
			
			if candidate == now { return }
			nodes.swapAt(now, candidate)
			now = candidate
		}
	}
	
	func getParent(of node: Int) -> Int {
		return (node - 1) / 2
	}
	
	func getChilds(of node: Int) -> (left: Int, right: Int) {
		return (node * 2 + 1, node * 2 + 2)
	}
}

struct PriorityQueue<T: Comparable> {
	private var heap: Heap<T>
	
	var isEmpty: Bool { heap.isEmpty }
	var count: Int { heap.count }
	var top: T? { heap.top }
	
	init(type: Heap<T>.HeapType) {
		self.heap = Heap(type: type)
	}
	
	mutating func push(_ element: T) {
		heap.insert(element)
	}
	
	@discardableResult
	mutating func pop() -> T? {
		heap.pop()
	}
}

struct FlowerDate: Comparable {
	let month: Int
	let day: Int
	
	static func < (lhs: FlowerDate, rhs: FlowerDate) -> Bool {
		if lhs.month == rhs.month {
			return lhs.day < rhs.day
		} else {
			return lhs.month < rhs.month
		}
	}
}

struct Flower: Comparable {
	let stDate: FlowerDate
	let enDate: FlowerDate
	
	init(_ stMonth: Int, _ stDay: Int, _ enMonth: Int, _ enDay: Int) {
		self.stDate = FlowerDate(month: stMonth, day: stDay)
		self.enDate = FlowerDate(month: enMonth, day: enDay)
	}
	
	init(_ arr: [Int]) {
		self.init(arr[0], arr[1], arr[2], arr[3])
	}
	
	static func < (lhs: Flower, rhs: Flower) -> Bool {
		lhs.enDate < rhs.enDate
	}
}

func solution() {
	let n = readInteger()
	var result = 0
	var flowers = [Flower]()
	var currentEnDate = FlowerDate(month: 3, day: 1)
	let targetEnDate = FlowerDate(month: 12, day: 1)
	var priorityQueue = PriorityQueue<Flower>(type: .max)
	
	for _ in (0..<n) {
		let informations = readIntergers()
		flowers.append(.init(informations))
	}
	
	// 시작날짜 기준으로 정렬
	let sortedFlowers = flowers.sorted {
		$0.stDate < $1.stDate
	}

	var flowerIndex = 0
	
	while currentEnDate < targetEnDate {
		// 현재의 꽃이 지는날보다, 먼저 피는 꽃들을 우선순위 큐에 삽입한다.
		while
			flowerIndex < sortedFlowers.count &&
			sortedFlowers[flowerIndex].stDate <= currentEnDate {
			
			priorityQueue.push(sortedFlowers[flowerIndex])
			flowerIndex += 1
		}

		// 이후, 가장 늦게 지는 꽃을 선택한다.
		if let date = priorityQueue.pop() {
			currentEnDate = date.enDate
			result += 1
		} else {
			break
		}
	}
	
	currentEnDate >= targetEnDate ? print(result) : print(0)
}

func readInteger() -> Int {
	Int(readLine()!)!
}

func readIntergers() -> [Int] {
	return readLine()!.split(separator: " ").map { Int($0)! }
}

solution()

C++

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

using namespace std;

#define FAST ios::sync_with_stdio(0),cin.tie(0),cout.tie(0)
#define endl '\n'

struct Date {
	int month = 0, day = 0;
};

int N;
vector<pair<Date, Date>> arr;

bool compareDate(Date a, Date b) {
	if(a.month == b.month) return a.day < b.day;
	return a.month < b.month;
}

bool compare1(pair<Date, Date> a, pair<Date, Date> b) {
	return compareDate(a.first, b.first);
}

bool compare2(pair<Date, Date> a, pair<Date, Date> b) {
	return compareDate(a.second, b.second);
}

void input() {
	cin >> N;
	
	Date date1, date2;
	for(int i = 0; i < N; i++) {
		cin >> date1.month >> date1.day >> date2.month >> date2.day;
		arr.push_back({date1, date2});
	}
}

bool isFinish(Date &a) {
	Date temp;
	temp.month = 11;
	temp.day = 30;
	
	return compareDate(temp, a);
}

int solve() {
	sort(arr.begin(), arr.end(), compare1);
	
	vector<pair<Date, Date>> temp;
	
	Date currentDate;
	currentDate.month = 3; currentDate.day = 1;
	int index = 0;
	int cnt = 0;
	while(index < N) {
		if(isFinish(currentDate)) return cnt;

		while(index < N && !compareDate(currentDate, arr[index].first)) {
			temp.push_back(arr[index ++]);
		}

		if(temp.size() == 0) return 0;
		sort(temp.begin(), temp.end(), compare2);
		currentDate = temp[temp.size()-1].second;
		cnt++;
		
		temp.clear();
	}

	if(!isFinish(currentDate)) return 0;
	return cnt;
}

int main() {
	FAST;
	input();
	cout << solve() << endl;
}

[PS] BOJ 1539(이진 검색 트리)

seok-young — Tue, 18 Jun 2024 23:08:26 +0900

https://www.acmicpc.net/problem/1539

문제 접근

가장 먼저 생각할 수 있는 방법은 BST를 직접 구현해, 삽입될 때마다 위치를 확인하는 방법이다.

하지만, N = 250,000이고, BST가 편향 트리가 되는 경우 탐색 시간은 $O(logN)$이 아닌, $O(N)$이 되게 되어,

최종 시간 복잡도는 $O(N^2)$으로 시간초과가 발생하게 된다.

그렇다면, Self-Balancing 트리를 사용하면서 BST상에서 노드의 높이를 알 수 있어야만 한다.

이때, 노드가 삽입될 때, 부모 노드의 높이를 알 수만 있다면, 각 노드의 높이를 계산할 수 있을 것이다.

따라서, Self-Balancing 트리에서 새로운 노드가 삽입되는 부모 노드를 알아야 한다.

트리에서 새로운 노드는 "자신보다 바로 작거나 큰 값을 가진 노드"의 자식으로 삽입될 것이다.

우선, "자신보다 바로 큰 값을 가진 노드"의 자식으로 삽입되는 상황을 살펴보자.

해당 경우에는 왼쪽 자식으로 삽입되게 될 것이다.

하지만, 왼쪽 자식이 있는 경우라면, "자신보다 바로 작은 값을 가진 노드"의 자식으로 삽입되어야 한다.

해당 경우에는 오른쪽 자식으로 삽입되게 될 것이다.

그렇다면, 오른쪽 자식이 있는 경우라면 어떻게 될까?

결론부터 말하자면, "자신보다 바로 큰 값을 가진 노드"부터 확인한다면, 해당 경우는 존재하지 않는다.

만약, 삽입되는 노드를 X라고 가정하고, 부모 노드를 Y라고 가정하자.

노드 X와 노드 Y의 값들을 각각 $x$, $y$라고 가정한다면,

"자신보다 바로 작은 값을 가진 노드"의 자식으로 삽입되었기 때문에, 항상 $y < x$를 만족한다.

이때, Y의 오른쪽 자식을 K라고 가정해 보고, 값을 $k$라고 가정해 보자.

그렇다면 $y < k$가 되며, 노드 K는 "X보다 바로 큰 값을 가진 노드"가 된다.

노드 Y가 "X보다 바로 작은 값을 가진 노드"이기 때문에, $y < k < x$는 성립할 수 없다.

하지만, 해당 케이스는 우선적으로 "자신보다 바로 큰 값을 가진 노드"부터 확인한 경우라면,

Y의 오른쪽 자식이 존재할 수 있는 경우는 없다.

문제 풀이

즉, 이를 코드로 옮겨보자면 다음과 같다.

우선, lower_bound를 통해 "자신보다 바로 큰 값을 가진 노드"를 확인한다.

하지만, 자신보다 바로 큰 값이 없는 경우, 해당 경우는 삽입되는 노드가 가장 큰 값이다.

따라서, "자신보다 바로 작은 값을 가진 노드"의 오른쪽 자식으로 삽입한다.

auto iter = node.lower_bound(num);

if(iter == node.end()) {
	advance(iter, -1);
	
	iter->second.hasRight = true;
	node[num] = {false, false, iter->second.height + 1};
}

다음으로, "자신보다 바로 큰 값을 가진 노드"의 왼쪽 자식이 이미 존재하는 경우에는 "자신보다 바로 작은 값을 가진 노드"의 오른쪽 자식으로 삽입한다.

반대의 경우 왼쪽 자식으로 그대로 삽입하면 된다.

else {
	// 왼쪽이 있는 경우
	if(iter->second.hasLeft) {
		advance(iter, -1);
		
		iter->second.hasRight = true;
		node[num] = {false, false, iter->second.height + 1};
		// 왼쪽이 없는 경우
	} else {
		iter->second.hasLeft = true;
		node[num] = {false, false, iter->second.height + 1};
	}
}

전체 코드

#include <iostream>
#include <map>

using namespace std;

#define FAST ios::sync_with_stdio(0),cin.tie(0),cout.tie(0)
#define endl '\n'
#define ll long long

struct NodeInfo {
	bool hasLeft, hasRight;
	int height;
};

int N;
map<int, NodeInfo> node;

ll solve() {
	ll total = 0;
	cin >> N;
	
	int num;
	for(int i = 0; i < N; i++) {
		cin >> num;
		if(node.size() == 0) {
			node[num] = {false, false, 1};
			continue;
		}
		
		auto iter = node.lower_bound(num);
		
		if(iter == node.end()) {
			advance(iter, -1);
			
			iter->second.hasRight = true;
			node[num] = {false, false, iter->second.height + 1};
		} else {
			// 왼쪽이 있는 경우
			if(iter->second.hasLeft) {
				advance(iter, -1);
				
				iter->second.hasRight = true;
				node[num] = {false, false, iter->second.height + 1};
			// 왼쪽이 없는 경우
			} else {
				iter->second.hasLeft = true;
				node[num] = {false, false, iter->second.height + 1};
			}
		}
	}
	
	for(auto res: node) {
		total += res.second.height;
	}
	
	return total;
}

int main(){
	FAST;
	cout << solve() << endl;
}

[Data Structure] Tree(5) - Red-Black Tree Implementation

seok-young — Mon, 17 Jun 2024 01:42:50 +0900

이번 포스팅에선 "Red-Black Tree"를 Swift로 구현할 것이다.

만약 개념에 대한 내용이 궁금하다면 해당 포스팅을 참고 바란다.

자세한 구현은 아래 링크에서 확인해 볼 수 있다.

https://github.com/jungseokyoung-cloud/Data-Structure/tree/main/Data-Structure/Tree.playground/Sources/Red-BlackTree

Data-Structure/Data-Structure/Tree.playground/Sources/Red-BlackTree at main · jungseokyoung-cloud/Data-Structure

Data Structures implemented with Swift. Contribute to jungseokyoung-cloud/Data-Structure development by creating an account on GitHub.

github.com

RedBlack Node

우선, RedBlackNode는 다음과 같이 구현해 준다.

final class RedBlackNode<T: Comparable>: Node<T> {
	var isRed: Bool = true
	
	required init(value: T) {
		super.init(value: value)
	}
	
	required init(value: T, parent: Node<T>?) {
		super.init(value: value, parent: parent)
	}
}

색깔을 구분하기 위 한 ~~isRed~~ 프로퍼티를 추가한다.

RedBlack Tree

RB 트리에서 NIL노드는 별도의 메모리를 할당하지 않고, 단순히 ~~nil~~로 지정했다.

insert(_:)

public override func insert(_ value: T) {
	guard let node = super.performInsert(value) as? RedBlackNode<T> else { return }
	
	insertBalancing(for: node)
}

~~insert(_:)~~ 메서드는 insert수행한 후, ~~insertBalancing(for:)~~ 메서드를 수행한다.

insertBalancing(for:)

@discardableResult
func insertBalancing(for node: RedBlackNode<T>) -> RedBlackNode<T>? {
	guard node !== root else {
		node.isRed = false
		return node
	}
	
	// 연속해서 빨간색이 나오지 않는 경우, 종료
	guard
		let parent = node.parent as? RedBlackNode<T>,
		parent.isRed
	else { return node }
	
	if let uncle = node.uncle as? RedBlackNode<T>, uncle.isRed {
		return recoloring(for: node)
	} else {
		return restructuring(for: node)
	}
}

~~insertBalancing(for:)~~메서드는 restructuring을 할지 recoloring을 할지 결정하는 메서드이다.

우선, 부모노드가 빨간색인 경우 #4 조건을 위반하게 되어, self-balancing이 필요하다.

#4: 빨간색 노드의 자식은 검은색이다. (즉, 2 연속으로 빨간색이 나올 수 없다.)

// 연속해서 빨간색이 나오지 않는 경우, 종료
guard
	let parent = node.parent as? RedBlackNode<T>,
	parent.isRed
else { return node }

그렇기 때문에 다음과 같이 부모 노드가 검은색일 경우, 다음과 같이 종료한다.

if let uncle = node.uncle as? RedBlackNode<T>, uncle.isRed {
	return recoloring(for: node)
} else {
	return restructuring(for: node)
}

다음으로, 삼촌 노드가 빨간색일 경우 recoloring을 수행하고,

검은색일 경우, restructing을 수행한다.

restructuring(for:)

@discardableResult
func restructuring(for node: RedBlackNode<T>) -> RedBlackNode<T>? {
	guard
		let parent = node.parent as? RedBlackNode<T>,
		let grandParent = parent.parent as? RedBlackNode<T>
	else { return node }
	grandParent.isRed = true

	// LL Case
	if node.isLeftChild && parent.isLeftChild {
		parent.isRed = false
		return rightRotate(for: grandParent, pivot: parent)
		
	// RR Case
	} else if node.isRightChild && parent.isRightChild {
		parent.isRed = false
		return leftRotate(for: grandParent, pivot: parent)
		
	// LR Case
	} else if node.isRightChild && parent.isLeftChild {
		node.isRed = false
		let pivot = leftRotate(for: parent, pivot: node)
		return rightRotate(for: grandParent, pivot: pivot)
		
	// RL Case
	} else {
		node.isRed = false
		let pivot = rightRotate(for: parent, pivot: node)
		return leftRotate(for: grandParent, pivot: pivot)
	}
}

RR Case, LL Case의 경우 부모 노드와 조부모 노드의 색상을 변경해 주고, Rotation 작업을 수행한다.

또한, RL Case, LR Case의 경우 새로운 노드와 조부모 노드의 색상을 변경한 후, Rotation 작업을 수행한다.

이때, NIL노드가 삼촌노드일수도 있기 때문에, 다음과 같이 optional 바인딩을 진행해 준다.

recoloring(for:)

@discardableResult
func recoloring(for node: RedBlackNode<T>) -> RedBlackNode<T>? {
	guard
		let parent = node.parent as? RedBlackNode<T>,
		let grandParent = parent.parent as? RedBlackNode<T>,
		let uncle = node.uncle as? RedBlackNode<T>
	else { return node }
	
	grandParent.isRed = true
	parent.isRed = false
	uncle.isRed = false
	
	return insertBalancing(for: grandParent)
}

~~recoloring(for:)~~메서드는 다음과 같이 부모노드와, 삼촌 노드를 검은색으로 변경한다.

이후, 조부모 노드를 빨간색으로 변경한다.

하지만, 조부모 노드에서 다시 #4조건을 위반할 수 있기 때문에, 재귀적으로 ~~insertBalancing(for:)~~메서드를 수행해 준다.

remove(_:)

public override func remove(_ value: T) -> T? {
	guard let removeNode = search(value) else { return nil }

	let removedReturnType = super.performRemove(node: removeNode)
	removeBalancing(
		removedNode: removedReturnType.removedNode,
		replaceNode: removedReturnType.replaceNode,
		parentNode: removedReturnType.parentNode
	)
	
	return removeNode.value
}

~~remove(_:)~~메서드는 ~~removeBalancing(removedNode:replaceNode:parentNode:)~~를 통해 균형을 잡는다.

removeBalancing(removedNode:replaceNode:parentNode:)

func removeBalancing(
	removedNode: Node<T>?,
	replaceNode: Node<T>?,
	parentNode: Node<T>?
) {
	guard let node = removedNode as? RedBlackNode<T>, !node.isRed else { return }
	
	// 삭제된 노드가 검정색이라면, Extra-Black을 부여
	removeExtraBlack(parent: parentNode, replaceNode: replaceNode)
	
	(root as? RedBlackNode<T>)?.isRed = false
}

~~removeBalancing~~은 삭제되는 노드가 검은색이라면, 문제가 발생한다. 따라서, guard문을 통해 삭제되는 노드가 검은색인지 확인한다.

다음으로, ~~removeExtraBlack~~메서드를 통해 ExtraBlack을 제거한다.

removeExtraBlack(parent:replaceNode:)

func removeExtraBlack(parent: Node<T>?, replaceNode: Node<T>?) {
	// Red-And-Black Node
	if let replaceNode = replaceNode as? RedBlackNode<T>, replaceNode.isRed {
		replaceNode.isRed = false
	} else {
		removeDoublyBlack(parent: parent, doublyBlack: replaceNode)
	}
}

이때, ~~replaceNode~~는 삭제된 노드의 위치에 위치한 노드이다.

~~replaceNode~~가 빨간색이라면, Red-And-Black이므로 검은색으로 변경해 주면 되지만,

Double-Black이라면 여러 분기로 나뉘기 때문에, ~~removeDoublyBlack~~메서드를 통해 제거한다.

removeDoublyBlack(parent:doublyBlack:)

func removeDoublyBlack(parent: Node<T>?, doublyBlack: Node<T>?) {
	guard
		let parent = parent as? RedBlackNode<T>,
		let sibling = (parent.left === doublyBlack ? parent.right : parent.left) as? RedBlackNode<T>
	else { return }
	
	if !sibling.isRed {
		if
			let sibilingChild = (sibling.isLeftChild ? sibling.left : sibling.right) as? RedBlackNode<T>,
			sibilingChild.isRed {
			removeCase4(
				parent: parent,
				sibling: sibling,
				child: sibilingChild
			)
		} else if
			let sibilingChild = (sibling.isLeftChild ? sibling.right : sibling.left) as? RedBlackNode<T>,
			sibilingChild.isRed {
			removeCase3(
				parent: parent,
				sibling: sibling,
				child: sibilingChild
			)
		} else {
			removeCase2(parent: parent, sbiling: sibling)
		}
	} else {
		removeCase1(parent: parent, sibling: sibling, node: doublyBlack as? RedBlackNode<T>)
	}
}

분기가 복잡해 보이지만 살펴보면 단순하다.

우선, 형제노드의 색깔이 검은색이고, 형제노드와 같은 위치의 형제노드의 자식(LL 혹은 RR)이 빨간색인 경우,

if !sibling.isRed {
	if
		let sibilingChild = (sibling.isLeftChild ? sibling.left : sibling.right) as? RedBlackNode<T>,
		sibilingChild.isRed {
		removeCase4(
			parent: parent,
			sibling: sibling,
			child: sibilingChild
		)
	}

case4에 해당되기 때문에, ~~removeCase4~~메서드를 통해 Doubly-Black을 제거해 준다.

다음으로, 형제노드의 색깔이 검은색이고, 형제노드와는 반대편 위치에 존재하는 형제노드의 자식(LR 혹은 RL)이 빨간색이고,

같은 위치의 형제노드는(LL 혹은 RR)이 검은색인 경우,

if !sibling.isRed {
	...
	} else if
		let sibilingChild = (sibling.isLeftChild ? sibling.right : sibling.left) as? RedBlackNode<T>,
		sibilingChild.isRed {
		removeCase3(
			parent: parent,
			sibling: sibling,
			child: sibilingChild
		)
	}

case3에 해당하여 ~~removeCase3~~메서드를 통해 Doubly-Black을 제거해 준다.

만약, 형제노드가 검은색이고, 형제노드의 두 자식 다 검은색이라면,

if !sibling.isRed {
	...
	} else {
		removeCase2(parent: parent, sbiling: sibling)
	}
}

case2이므로, ~~removeCase2~~메서드를 통해 Doubly-Black을 제거해 준다.

마지막으로 형제노드가 빨간색인 경우는 case1에 해당되므로 ~~removeCase1~~메서드를 호출한다.

else {
	removeCase1(parent: parent, sibling: sibling, node: doublyBlack as? RedBlackNode<T>)
}

removeCase4(parent:sibling:child:)

func removeCase4(
	parent: RedBlackNode<T>,
	sibling: RedBlackNode<T>,
	child: RedBlackNode<T>
) {
	sibling.isRed = parent.isRed
	
	child.isRed = false
	parent.isRed = false
	
	if sibling.isLeftChild {
		rightRotate(for: parent, pivot: sibling)
	} else {
		leftRotate(for: parent, pivot: sibling)
	}
}

형제노드는 부모노드의 색상으로 변경하고, 형제노드의 자식노드와 부모노드를 검은색으로 변경한다.

이후, 각 상황에 맞게 rotation을 수행한다.

removeCase3(parent:sbling:child:)

func removeCase3(
	parent: RedBlackNode<T>,
	sibling: RedBlackNode<T>,
	child: RedBlackNode<T>
) {
	sibling.isRed = true
	child.isRed = false
	
	if sibling.isLeftChild {
		leftRotate(for: sibling, pivot: child)
	} else {
		rightRotate(for: sibling, pivot: child)
	}
	
	guard
		let newChild = (sibling.isLeftChild ? child.left : child.right) as? RedBlackNode<T>
	else { return }
	
	removeCase4(parent: parent, sibling: child, child: newChild)
}

해당 경우에는 형제노드를 빨간색으로, 형제의 자식노드를 검은색으로 변경한다.

이후, Rotation 작업을 진행해 주게 되면 case4가 되기 때문에 ~~removeCase4~~를 호출해 준다.

removeCase2(parent:sibling:)

func removeCase2(parent: RedBlackNode<T>, sibling: RedBlackNode<T>) {
	sibling.isRed.toggle()
	// 부모에게 Extra-Black을 위임
	removeExtraBlack(parent: parent.parent, replaceNode: parent)
}

형제노드의 색상을 변경해 주고, Extra-Black을 부모에게 넘겨준다.

이후 부모노드에게 ExtraBlack을 위임한다.

removeCase1(parent:sibling:node:)

func removeCase1(parent: RedBlackNode<T>, sibling: RedBlackNode<T>, node: RedBlackNode<T>?) {
	parent.isRed = true
	sibling.isRed = false
	
	if sibling.isLeftChild {
		rightRotate(for: parent, pivot: sibling)
	} else {
		leftRotate(for: parent, pivot: sibling)
	}
	
	removeDoublyBlack(parent: parent, doublyBlack: node)
}

case1의 경우에는 부모 노드와 형제노드의 색상을 변경한 후, rotation 작업을 수행한다.

이후 case2, case3, case4에 맞춰서 DoublyBlack을 해결하면 된다.