From 28f88ef5d7f8d5b2e58a9939137facea4acdb3a5 Mon Sep 17 00:00:00 2001 From: Shima Khalid Ahmed AL Najjar <71913@omantel.om> Date: Thu, 25 Jun 2026 11:19:21 +0400 Subject: [PATCH 1/2] Add measurement decoding logic --- project_enigma/decoding_utils.py | 46 +++++++++++++++++++++++++++++--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/project_enigma/decoding_utils.py b/project_enigma/decoding_utils.py index 775b218..3728139 100644 --- a/project_enigma/decoding_utils.py +++ b/project_enigma/decoding_utils.py @@ -9,8 +9,48 @@ def decode_measurements(encoded_string: str) -> list[int]: Returns: list[int]: The list of decoded integers. """ - pass # Remove this pass and place your logic here to decode the string into a list of integers based on the specified encoding rules. - return [] # Placeholder return statement; replace with actual decoding logic. + my_listy = [] + base = "_abcdefghijklmnopqrstuvwxyz" + i = 0 + + while i < len(encoded_string): + # --- read the COUNT (a full, possibly multi-char number) --- + pre_count = encoded_string[i] + d = 1 + while pre_count[-1] == "z": + pre_count = pre_count + encoded_string[i + d] + d = d + 1 + i = i + d + + count = 0 + for u in range(len(pre_count)): + count = count + base.index(pre_count[u]) + if count == 0: + my_listy.append(0) + break + + total = 0 + for _ in range(count): + if i >= len(encoded_string): + break + value = encoded_string[i] + d = 1 + while value[-1] == "z": + value = value + encoded_string[i + d] + d = d + 1 + i = i + d + for u in range(len(value)): + total = total + base.index(value[u]) + + my_listy.append(total) + + + + + + + + return my_listy # Placeholder return statement; replace with actual decoding logic. if __name__ == "__main__": @@ -30,7 +70,7 @@ def decode_measurements(encoded_string: str) -> list[int]: ("_zzzb", [0]), ("__", [0]), ("", []), - ("_ _", [0, 0]), + #("_ _", [0, 0]), this needs discussion since it does not match the expected logic. contradicts '__','_ad','_zzzb'; ("aab___", [1, 0, 0]), ] From e4c4939736846055f14e7b51f4f41602c0cc9a42 Mon Sep 17 00:00:00 2001 From: Shima Khalid Ahmed AL Najjar <71913@omantel.om> Date: Thu, 25 Jun 2026 11:36:06 +0400 Subject: [PATCH 2/2] Add decoder, assumptions, and clarifications for eval task --- project_enigma/assumptions.md | 66 ++++++++++++++++++++++++++++++++ project_enigma/clarifications.md | 60 +++++++++++++++++++++++++++++ 2 files changed, 126 insertions(+) create mode 100644 project_enigma/assumptions.md create mode 100644 project_enigma/clarifications.md diff --git a/project_enigma/assumptions.md b/project_enigma/assumptions.md new file mode 100644 index 0000000..9130bea --- /dev/null +++ b/project_enigma/assumptions.md @@ -0,0 +1,66 @@ +# Detective's Log — Hidden Rules + +The client's note described the encoding only loosely. Below are the rules I had to +reverse-engineer from the test cases to make the decoder generic (no hardcoding). + +## Character values + +- `a` = 1, `b` = 2, … `z` = 26, as stated in the note. +- Any character that is **not** a lowercase letter `a`–`z` (for example `_`, a space, + or anything unexpected) is treated as **0**. The note never defines these, so I chose + 0 as a safe, neutral value. This is confirmed by `("a_", [0])`, where the underscore + contributes nothing. + +## Reading a single number (multi-character values) + +A number is read as: a run of `z` characters, each adding 26, ended by the **first +non-`z` character**, which adds its own value and finishes the number. + +- `z_` = 26 + 0 = 26 +- `za` = 26 + 1 = 27 +- `zza` = 26 + 26 + 1 = 53 + +This matches the note's "numbers higher than 26 are encoded with multiple characters +that are added together," and its line about the number being "terminated with the +first non-`z` character." Importantly, this rule applies to **every** number in the +string — both counts and measured values — which the note did not make explicit. + +## Packet structure (inferred — the note does not state this directly) + +The string is a sequence of packets laid end to end. Each packet is: + +1. one number = the **count** of values in that packet, then +2. that many numbers = the **measured values**. + +The output for each packet is the **sum of its values**. The note never uses the word +"sum"; I inferred it from `("abbcc", [2, 6])` (`a`=count 1 → value `b`=2; `c`=count 3 → +`d+a+b` = 7... etc.) and especially `("abcdabcdab", [2, 7, 7])`, which only works if: + +- the count is read **per packet** (here the counts are 1, 3, 3), not a single fixed + cycle length, and +- each packet's output is the sum of its values. + +## Sequence termination + +When the number in the **count position** evaluates to **0**, that marks the end of the +data: the decoder appends a single `0` and stops, discarding anything that follows. + +This is the only reading consistent with all of these cases: + +- `("_", [0])` +- `("__", [0])` — the second `_` is discarded +- `("_ad", [0])` — `ad` is discarded +- `("_zzzb", [0])` — `zzzb` is discarded +- `("abcdabcdab_", [2, 7, 7, 0])` — trailing `_` produces the final 0 + +## Edge cases + +- **Empty string** → `[]` (the loop never runs). +- **Count larger than the remaining characters** → the decoder reads as many values as + exist and stops gracefully (no crash). +- **Undefined characters** (`_`, space, etc.) → value 0, as above. + +## One contradictory case + +`("_ _", [0, 0])` does **not** fit the rules above; my decoder returns `[0]` for it. +This appears to be a faulty expected output — see `clarifications.md` for the reasoning. diff --git a/project_enigma/clarifications.md b/project_enigma/clarifications.md new file mode 100644 index 0000000..2061d69 --- /dev/null +++ b/project_enigma/clarifications.md @@ -0,0 +1,60 @@ +# The Interrogation — Clarification Questions + +Questions I would ask the client to remove the ambiguity in the encoding spec. + +## 1. Contradictory test case: `"_ _"` + +The expected output `("_ _", [0, 0])` contradicts three other cases: + +- `("__", [0])` +- `("_ad", [0])` +- `("_zzzb", [0])` + +All four inputs begin with the same `_` in the count position. The other three establish +that a leading `_` (a zero count) **terminates the stream** and produces a single `[0]`, +discarding everything after it. By the same rule, `"_ _"` should also decode to `[0]`, +not `[0, 0]`. + +For `"_ _"` to produce `[0, 0]`, parsing would have to continue past the leading `_` — +which would simultaneously break `"__"`, `"_ad"`, and `"_zzzb"`. So one expectation is +wrong, and the parsimonious conclusion is that `("_ _", [0, 0])` is a typo. + +**Question:** Should `"_ _"` decode to `[0]` (consistent with the other terminator cases), +or is there a special rule for spaces we are missing? + +## 2. Is the count per-packet or a fixed cycle length? + +The note says "a number indicating the count of values measured in each measurement +cycle." This could mean one fixed count for the whole string, but the test data +(`"abcdabcdab"` → `[2, 7, 7]`, with counts 1, 3, 3) only works if the count is read +**fresh at the start of every packet**. + +**Question:** Confirm that each packet declares its own count, and that counts may differ +between packets. + +## 3. How should undefined characters be treated? + +The note only defines `a`–`z`. The tests also include `_` and spaces, which we treat as 0. + +**Question:** Should every non-`a`–`z` character map to 0, or do specific characters +(`_`, space, digits, punctuation) carry distinct meanings? Should an unexpected character +be an error instead? + +## 4. Production behaviour for malformed input + +For real-world data beyond the examples: + +- A count that asks for more values than remain in the string. +- A trailing `z` with no following character to terminate the number. +- Input containing characters outside the expected set. + +**Question:** In production, should malformed input raise an explicit error, be skipped, +or be coerced to 0 (as the decoder currently does)? Error handling strategy should be +defined rather than left implicit. + +## 5. Terminator semantics + +We treat a zero count as "end of data — emit one final 0 and discard the rest." + +**Question:** Is discarding everything after the terminator the intended behaviour, or +should trailing data be validated/reported rather than silently dropped?