처음이어도 괜찮아요 · 그림부터 시작해요
chaining resize와 rehash
capacity가 바뀌면 각 live entry의 새 bucket index를 다시 계산하고 old chain links를 새 table에 안전하게 재구성한다. 이를 생략하면 old bucket 번호를 복사해 lookup miss나 orphan entry를 만든다.에서도 작은 예시는 맞을 수 있지만 충돌·삭제·재해시·적대 입력에서 재현 가능한 판단은 남지 않습니다.
아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.01 · 가볍게 시작하기
정답을 보기 전에 먼저 골라볼까요?
ht16 · fixed hash outputs · collision/duplicate/delete/threshold fixtures · bounded capacity- 1먼저 골라보기
틀려도 괜찮아요. 지금 생각한 답 하나를 정해요.
- 2그림으로 확인하기
움직이는 순서와 달라지는 곳만 천천히 찾아요.
- 3내 말로 다시 말하기
한 문장으로 말해 보면 내가 이해한 곳을 확인할 수 있어요.
02 · 그림으로 보기
그림이 움직이는 순서를 직접 확인해요
- 01관찰resize · rehash · entry conservation
- 02추론capacity가 바뀌면 각 live entry의 새 bucket index를 다시 계산하고 old chain links를 새 table에 안전하게 재구성한다. chaining resize와 rehash의 correctness는 equal key가 같은 lookup 경로에 도달하고 collision strategy가 다른 key를 보존하는지로 판정한다. old/new capacity·hash·bucket·entry-count migration ledger에는 operation별 hash output·bucket/probe·equality check·slot state·result를 남긴다. in-memory index growth·migration로 전이할 때 runtime 구현, 공격자 통제, 동시 수정과 iteration 계약을 새로 감사한다.
- 03검증chaining resize와 rehash의 key identity, hash/equality, capacity와 observable operation 계약을 AI 없이 먼저 고정한다. old bucket 번호를 복사해 lookup miss나 orphan entry를 만든다.를 collision·duplicate·delete·threshold 중 해당하는 최소 반례로 재현한다. bucket/slot state와 logical map/set state, expected·amortized·worst/observed 비용을 구분한다. old/new capacity·hash·bucket·entry-count migration ledger와 사람의 accept·revise·reject 판정 및 보장하지 않는 범위를 제출한다.
처음 보는 말도 책 읽듯 풀어봐요
이 수업은 쉬운 뜻과 생활 예를 아직 함께 준비하지 못했어요. 설명 없는 정확한 이름은 먼저 보여 주지 않을게요.
그림에서 찾을 쉬운 규칙
- 01capacity가 바뀌면 각 live entry의 새 bucket index를 다시 계산하고 old chain links를 새 table에 안전하게 재구성한다.
- 02chaining resize와 rehash의 correctness는 equal key가 같은 lookup 경로에 도달하고 collision strategy가 다른 key를 보존하는지로 판정한다.
- 03old/new capacity·hash·bucket·entry-count migration ledger에는 operation별 hash output·bucket/probe·equality check·slot state·result를 남긴다.
- 04in-memory index growth·migration로 전이할 때 runtime 구현, 공격자 통제, 동시 수정과 iteration 계약을 새로 감사한다.
03 · 같이 풀어보기
한 단계씩 따라가면 어렵지 않아요
in-memory index growth·migration의 축소된 합성 key operation stream에서 chaining resize와 rehash 판단을 수행한다.
ht16 · fixed hash outputs · collision/duplicate/delete/threshold fixtures · bounded capacity04 · 이제 내가 해볼 차례
여기까지 오면 이런 일을 할 수 있어요
모든 entry 보존과 새 lookup equivalence를 검증한다.을 수행하고 old/new capacity·hash·bucket·entry-count migration ledger로 key 계약·충돌 처리·경계·claim level을 독립 검증한다.
- chaining resize와 rehash의 key identity, hash/equality, capacity와 observable operation 계약을 AI 없이 먼저 고정한다.
- old bucket 번호를 복사해 lookup miss나 orphan entry를 만든다.를 collision·duplicate·delete·threshold 중 해당하는 최소 반례로 재현한다.
- bucket/slot state와 logical map/set state, expected·amortized·worst/observed 비용을 구분한다.
- old/new capacity·hash·bucket·entry-count migration ledger와 사람의 accept·revise·reject 판정 및 보장하지 않는 범위를 제출한다.
05 · 자주 헷갈리는 지점
틀린 답도 이유를 알면 다음에는 맞힐 수 있어요
01chaining resize와 rehash에서는 서로 다른 key가 서로 다른 hash나 bucket을 가져야 correctness가 성립한다.
한 번 더 생각해 볼 질문in-memory index growth·migration에서 같은 hash를 가진 서로 다른 두 key를 안전하게 처리하는 trace를 쓰세요.
이렇게 고쳐 생각해요collision은 허용되며 capacity가 바뀌면 각 live entry의 새 bucket index를 다시 계산하고 old chain links를 새 table에 안전하게 재구성한다.과 equality 확인으로 서로 다른 key를 보존해야 한다.
02rehash operation은 hash table이므로 모든 입력과 runtime에서 항상 O(1)이다.
한 번 더 생각해 볼 질문old bucket 번호를 복사해 lookup miss나 orphan entry를 만든다.가 lookup work를 선형으로 늘리는 최소 key family를 제시하세요.
이렇게 고쳐 생각해요old/new capacity·hash·bucket·entry-count migration ledger에 collision multiplicity·load·rehash·worst case와 문서의 claim level을 분리해야 한다.
03AI 구현과 AI가 만든 expected table이 일치하면 chaining resize와 rehash의 correctness·security·thread safety가 독립 검증된다.
한 번 더 생각해 볼 질문old bucket 번호를 복사해 lookup miss나 orphan entry를 만든다.를 드러내는 AI-off fixture와 사람이 확인할 oracle을 쓰세요.
이렇게 고쳐 생각해요같은 생성 가정을 공유한 결과는 oracle이 아니며 frozen model·mutation test·공식 source claim을 별도로 확인해야 한다.
06 · 더 궁금할 때만 보기