- Question 7
You have developed a scoring system for positive integers that works as follows:
- +2 points for every 5 found in the number.
For example, 5751 would score 4 points. - +4 points for each pair of consecutive 3s.
If there are more than two 3s in a row, add +4 for each additional 3, since it makes an additional pair (for example, four consecutive 3s gives +12). - +N² points for a sequence of length N (N ≥ 1) where each digit is 1 more than the previous digit.
For example, 9678562 would be (9-678-56-2) → 1 + 3² + 2² + 1 = 15 points. - +6 if the entire number is a multiple of 5.
- +1 for each odd digit.
Each component of the score is evaluated separately, so a given digit may contribute to more than one component. For example, the number 456 would score 9 for the sequence of length 3, 1 for one odd digit (5), and 2 for the 5 digit, for a total of 9 + 1 + 2 = 12.
Write a function compute_number_score
that computes (and returns) a score for an integer passed to it.
The number will be in the range 0 ≤ number < 1000000000.
- Question 8
Suppose we want to monitor how locks are used in our system. As the first step, we log moments of acquire and release for each lock in the following format:
- ACQUIRE X
- RELEASE X
where X is some integer ID (1 ≤ X ≤ 1,000,000) of the lock.
All locks must be released in the reverse order of acquiring them; for example, this is a correct event sequence:
- ACQUIRE 364
- ACQUIRE 84
- RELEASE 84
- ACQUIRE 1337
- RELEASE 1337
- RELEASE 364
However, the following sequence violates this rule because lock 84 is still acquired while releasing lock 364:
- ACQUIRE 364
- ACQUIRE 84
- RELEASE 364
- RELEASE 84
It’s also dangerous to leave locks acquired after application termination, as other processes in the system may be blocked while waiting on them, so such sequence is incorrect, too:
- ACQUIRE 364
- ACQUIRE 84
Output Rules:
- 0, if there were no lock-related problems even after program termination.
- N+1, if the only issue after program termination were dangling acquired locks.
- K, in case event number K violated any of the principles (release a lock not acquired previously, acquire an already held lock OR violate lock acquire-release ordering).
Examples:
Input:
- ACQUIRE 364
- ACQUIRE 84
- RELEASE 84
- RELEASE 364
Output: 0 (nothing bad happened)
Input:
- ACQUIRE 364
- ACQUIRE 84
- RELEASE 364
- RELEASE 84
Output: 3 (lock 84 should have been released before releasing 364)
Input:
- ACQUIRE 123
- ACQUIRE 364
- ACQUIRE 84
- RELEASE 84
- RELEASE 364
- ACQUIRE 456
Output: 7 (upon terminating, not all locks were released, namely 123 and 456).