왜 파이썬은 해시 테이블을 사용하여 dict를 구현하지만 Red-Black Tree는 구현하지 않습니까?
열쇠는 무엇입니까? 공연?
답변:
이것은 파이썬이 아닌 일반적인 답변입니다.
| Hash Table | Red-Black Tree |
-------+-------------+---------------------+
Space | O(n) : O(n) | O(n) : O(n) |
Insert | O(1) : O(n) | O(log n) : O(log n) |
Fetch | O(1) : O(n) | O(log n) : O(log n) |
Delete | O(1) : O(n) | O(log n) : O(log n) |
| avg :worst | average : worst |해시 테이블의 문제점은 해시가 충돌 할 수 있다는 것입니다. 충돌을 해결하기위한 다양한 메커니즘, 예를 들어 개방형 주소 지정 또는 별도의 체인 연결이 있습니다. 최악의 경우는 모든 키에 동일한 해시 코드가 있으며,이 경우 해시 테이블이 연결된 목록으로 저하됩니다.
다른 모든 경우에 해시 테이블은 구현하기 쉽고 우수한 성능을 제공하는 훌륭한 데이터 구조입니다. 단점은 빠르게 테이블을 늘리고 항목을 재분배 할 수있는 구현은 실제로 사용되는 메모리를 거의 낭비 할 수 있다는 것입니다.
RB- 트리는 자체 균형을 유지하며 최악의 경우 알고리즘 복잡성을 변경하지 않습니다. 그러나 구현하기가 더 어렵습니다. 평균 복잡도는 해시 테이블보다 복잡합니다.
해시 테이블의 모든 키는 서로 해시 가능하고 비교 가능해야합니다. 이것은 문자열이나 정수에 특히 쉽지만 사용자 정의 유형으로 확장하는 것도 매우 간단합니다. Java와 같은 일부 언어에서는 이러한 속성이 정의에 의해 보장됩니다.
RB-Tree의 키는 총 순서를 가져야합니다. 각 키는 다른 키와 비교 가능해야하며 두 키는 더 작거나 크거나 같아야합니다. 이 순서 평등은 시맨틱 평등과 동일해야합니다. 이것은 정수 및 기타 숫자에 대해 간단하며 문자열에도 상당히 쉽습니다 (순서는 일관성 있고 외부에서 관찰 할 수 없으므로 순서는 로케일을 고려할 필요가 없음 [1] ). . 서로 다른 유형의 키를 갖는 것은 불가능합니다.
[1] : 사실, 여기가 잘못되었습니다. 두 문자열은 바이트가 같지 않지만 일부 언어의 규칙에 따라 동일 할 수 있습니다. 두 개의 동일한 문자열이 다르게 인코딩되는 예는 유니 코드 정규화를 참조하십시오. 해시 키에 유니 코드 문자 구성이 중요한지 여부는 해시 테이블 구현에서 알 수없는 것입니다.
RB-Tree 키를위한 저렴한 솔루션은 먼저 동등성을 테스트 한 다음 동일성을 비교 (즉, 포인터 비교)하는 것이라고 생각할 수 있습니다. 그러나이 순서는 전 이적이지 않습니다. if a == b및 이면 순서 id(a) > id(c)를 따라야합니다 id(b) > id(c). 여기에서는 보장되지 않습니다. 대신, 키의 해시 코드를 조회 키로 사용할 수 있습니다. 여기서 순서는 올바르게 작동하지만 RB 트리에서 동일한 노드에 할당 될 동일한 해시 코드를 가진 여러 개의 고유 키로 끝날 수 있습니다. 이러한 해시 충돌을 해결하기 위해 우리는 해시 테이블과 마찬가지로 별도의 체인을 사용할 수 있지만 해시 테이블에 대한 최악의 동작을 상속합니다.
해시 테이블은 본질적으로 단지 배열이기 때문에 해시 테이블이 트리보다 더 나은 메모리 위치를 가질 것으로 기대합니다.
두 데이터 구조의 항목은 상당히 높은 오버 헤드를 갖습니다.
RB- 트리에서 삽입 및 삭제에는 트리 회전이 포함됩니다. 비용이 많이 들지는 않지만 오버 헤드가 발생합니다. 해시에서 삽입 및 삭제는 단순한 액세스보다 비용이 많이 들지 않습니다 (삽입시 해시 테이블의 크기를 조정하는 것은 O(n)노력 이지만 ).
해시 테이블은 본질적으로 변경 가능하지만 RB- 트리는 변경 불가능한 방식으로 구현 될 수도 있습니다. 그러나 이것은 거의 유용하지 않습니다.
여러 가지 이유가 있을 수 있지만 주요 이유는 다음과 같습니다.
쓰기 / 유지가 쉬우 며 일반적인 사용 사례에서 성능이 향상됩니까? 가입하세요!