Hash Collisions

Choose 4–256 buckets, a hash variant and a collision strategy. The first Insert, Sample, 32 keys or Reset action builds the table. Later valid settings redistribute the same source keys immediately; invalid capacity hides stale output without moving focus. Sample provides 12 fruit names; 32 keys is a fixed reproducible set. Reset empties the source set and keeps settings/key draft. Data opens examples, TXT and the source collection, including values not placed in the current table; remove buttons rebuild from the remaining order. This is reconstruction, not a tombstone-based hash-table deletion.

Keys are case-sensitive. Leading and trailing whitespace is removed; internal whitespace is kept. Empty keys are rejected. Each key has at most 256 UTF-16 code units and the table at most 1024 distinct keys. Duplicate keys do not change entries or counters.

Chaining keeps colliding keys in one bucket. Linear probing visits (start + offset) mod capacity until a free slot or duplicate, wrapping at the end. A full table cannot store another key, but the entered key remains in the source collection. Not placed counts source keys that cannot fit; increase capacity or select chaining to include them automatically. Duplicates remain recognizable without changing entries/counters. Start, destination and visited slots describe the last attempted insertion. Chaining counts one bucket visit, not list comparisons. The mean uses successful insertions only, excluding duplicates/failures. Reconfiguration rebuilds these derived values; typing a draft does not insert.

The hash variants operate on JavaScript UTF-16 code units. FNV-1a uses XOR and multiplication modulo 2³², djb2 uses h = 33h + unit; character sum ignores order and intentionally gives poor distribution. The retained Murmur3-style variant packs code units at shifts 0/8/16/24, including overlapping bits for non-ASCII units, and uses seed zero. These are not UTF-8 byte implementations of standard FNV or MurmurHash3 and are not cryptographic hashes.

Load factor is stored keys divided by bucket count; it can exceed one for chaining. Statistics include empty buckets, the longest bucket and mean bucket visits. The optional histogram groups buckets by their length; bars share a common scale. Example: with four buckets and character sum, ab and ba both start at bucket 3. For linear probing a/e/i/m all start at 1 and occupy 1/2/3/0 with 1/2/3/4 visits; q is rejected when full.

RFC 9923 · FNV; Austin Appleby · MurmurHash3.

Only raw capacity/hash/strategy/key draft, the canonical source-key order and disclosure preferences are saved, up to 100000 serialized characters. No bucket layout, probe counters or last operation is stored. Legacyv1 snapshots retain source keys but discard computed state. Reload/new views await an explicit action; already-mounted pinned views remain live in RAM. Oversized drafts retain the prior stored copy; download source keys and copy any other needed draft before reload. TXT contains one JSON-quoted source key per line, including currently unplaced keys, without session settings or results. Source removal/reconfiguration rebuilds from input order.

The table scrolls within its region. Long bucket lists scroll independently so one collision chain cannot stretch a row indefinitely; all keys remain available. The insertion average counts bucket visits, not comparisons within a chain.

Open the probe sequence to see the buckets in the order they were visited. Select a step to highlight its row in the table.