Build buckets keyed by a shared field, preserving the first-seen key order.

Algorithm

Canonical pairs (a,1), (b,2), (a,3), (c,4), (b,5) print {a: [1, 3], b: [2, 5], c: [4]}. The replay uses the same input in every language, so this Lua DSA implementation can be compared directly with the rest of the DSA track.

bucket map Each key owns a list. A new key creates a bucket; a repeated key appends to the existing bucket.

Basic Implementation

basic.lua
Replay: real traced execution (multi-file project)
local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}
local groups = {}
local order = {}
for _, pair in ipairs(pairs_data) do
  local key, value = pair[1], pair[2]
  if groups[key] == nil then
    groups[key] = {}
    table.insert(order, key)
  end
  table.insert(groups[key], value)
end
local parts = {}
for _, key in ipairs(order) do
  table.insert(parts, key .. ": [" .. table.concat(groups[key], ", ") .. "]")
end
print("{" .. table.concat(parts, ", ") .. "}")
  1. pairs ← [(a, 1), (b, 2), (a, 3), (c, 4), (b, 5)]

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}
    values this step[(a, 1), (b, 2), (a, 3), (c, 4), (b, 5)]pairs
  2. groups ← {}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{}groups
  3. groups ← {a: [1]}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{} {a: [1]}groupsakey1value
  4. groups ← {a: [1], b: [2]}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{a: [1]} {a: [1], b: [2]}groupsbkey2value
  5. groups ← {a: [1, 3], b: [2]}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{a: [1], b: [2]} {a: [1, 3], b: [2]}groupsakey3value
  6. groups ← {a: [1, 3], b: [2], c: [4]}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{a: [1, 3], b: [2]} {a: [1, 3], b: [2], c: [4]}groupsckey4value
  7. groups ← {a: [1, 3], b: [2, 5], c: [4]}

    1local pairs_data = {{"a", 1}, {"b", 2}, {"a", 3}, {"c", 4}, {"b", 5}}2local groups = {}3local order = {}
    values this step{a: [1, 3], b: [2], c: [4]} {a: [1, 3], b: [2, 5], c: [4]}groupsbkey5value
  8. stdout ← {a: [1, 3], b: [2, 5], c: [4]}

    15end16print("{" .. table.concat(parts, ", ") .. "}")
    values this step{a: [1, 3], b: [2, 5], c: [4]}stdout{a: [1, 3], b: [2, 5], c: [4]}groups
  9. bucket 1 after collision ← c -> a, degradation risk ← long chains can degrade lookup toward O(n)

    15end16print("{" .. table.concat(parts, ", ") .. "}")
    values this stepa c -> abucket 1 after collisionlong chains can degrade lookup toward O(n)degradation riskresize or rehash when load factor growsmitigationcnew key

Complexity

  • Time: O(n) average
  • Space: O(k + n) for buckets and values

Implementation notes

  • Keep output formatting deterministic. Do not rely on unordered hash-map printing when the lesson needs cross-language comparison.
  • The trace highlights the hash table state after each write and includes a collision contrast where one bucket chain grows, showing why long chains can degrade lookup and why real tables resize or rehash.