스칼라에서 List에 추가하는 데 왜 O (n) 시간이 복잡합니까?

방금 List(: +)에 대한 추가 작업의 실행 시간이 의 크기에 따라 선형으로 증가 한다는 것을 읽었습니다 List.

에 추가하는 List것은 꽤 일반적인 작업처럼 보입니다. 이를 수행하는 관용적 방법이 구성 요소 앞에 붙은 다음 목록을 바꾸어야하는 이유는 무엇입니까? 구현은 언제라도 변경 될 수 있으므로 설계 실패 일 수 없습니다.

내 관점에서, 선행과 추가는 모두 O (1)이어야합니다.

이것에 대한 정당한 이유가 있습니까?

내 의견을 조금 확장하겠습니다. 의 List[T]데이터 구조 scala.collection.immutable는보다 순전히 기능적인 프로그래밍 언어에서 변경 불가능한 목록이 작동하는 방식으로 작동하도록 최적화되었습니다. 접두사 시간 이 매우 빠르며 거의 모든 액세스를 위해 헤드에서 작업한다고 가정합니다.

불변 목록은 일련의 "콘 셀"로 연결된 목록을 모델링하기 때문에 매우 빠른 선행 시간을 갖습니다. 셀은 단일 값과 다음 셀에 대한 포인터를 정의합니다 (클래식 단일 링크 목록 스타일).

Cell [Value| -> Nil]

목록 앞에 추가하면 실제로 기존 목록의 나머지 부분을 가리키는 하나의 새 셀을 만드는 것입니다.

Cell [NewValue| -> [Cell[Value| -> Nil]]

목록은 변경할 수 없으므로 실제로 복사하지 않아도 안전합니다 . 이전 목록이 변경되어 새 목록의 모든 값이 유효하지 않게 될 위험은 없습니다. 그러나 타협으로 목록 끝 을 변경할 수있는 포인터를 가질 수 없습니다.

이것은 목록에서 재귀 적으로 작업하는 데 매우 적합합니다. 자신의 버전을 정의했다고 가정 해 봅시다 filter.

def deleteIf[T](list : List[T])(f : T => Boolean): List[T] = list match {
  case Nil => Nil
  case (x::xs) => f(x) match {
    case true => deleteIf(xs)(f)
    case false => x :: deleteIf(xs)(f)
  }
}

목록의 헤드에서만 독점적으로 작동하고 :: 추출기를 통해 패턴 일치를 이용하는 재귀 함수입니다. 이것은 Haskell과 같은 언어에서 많이 볼 수있는 것입니다.

빠른 추가를 원한다면 Scala는 선택할 수있는 많은 가변 및 불변 데이터 구조를 제공합니다. 변경 가능한 측면에서을 살펴볼 수 있습니다 ListBuffer. 또는 Vectorfrom scala.collection.immutable은 빠른 추가 시간이 있습니다.