Dataset Versioning: Why "the Same CSV" Is Not Reproducible Without a Hash
The problem, from first principles
01-experiment-tracking logged which hyperparameters and metrics produced a given model, but a training run also depends on WHICH DATA it saw, and "training_data_v3.csv" is a dangerously unreliable answer to "which data": the same filename can silently point to different bytes over time (re-exported, re-sorted, accidentally edited), and there's no way to tell just by looking at it. A content HASH is the only trustworthy answer to "is this really the same dataset?"
From theory to code
Implement compute_content_hash (the real fingerprint of raw bytes), hash_rows_naive (which inherits a genuine, non-obvious flaw), hash_rows_canonical (which fixes it), and datasets_are_identical.
Constraints
compute_content_hash(data_bytes)returns a SHA-256 hex digest: identical bytes always produce an identical hash.hash_rows_naive(rows)hashes the rows' representation directly, in whatever order they're given: reordering the SAME rows produces a DIFFERENT hash.hash_rows_canonical(rows)sorts the rows before hashing, so reordering the same rows produces the SAME hash.datasets_are_identical(hash_a, hash_b)is a plain equality check.
Hints
Open one at a time. Each gives away a little more than the last.
Hint 1
A hash function has no concept of "these rows mean the same thing in a different order": it only ever sees the exact bytes it's given, so hash_rows_naive inherits whatever order the input list happens to be in, faithfully and unhelpfully.
Hint 2
sorted(rows) before hashing is the entire fix: as long as the rows are sortable (comparable to each other), this guarantees any two lists containing the exact same rows, in ANY order, produce identical input to the hash function.
Keywords
No results yet
Run your code to check it against the examples, or submit to run every test.