Fix PR review comments: remove broken image links, fix space complexity, correct trace tables, fix SQL peak hours

vikahaze · vikahaze · commit 14a41d0d6556 · 2025-12-11T12:35:44.000+02:00
diff --git a/books/All.md b/books/All.md
@@ -10773,7 +10773,6 @@ https://leetcode.com/problems/design-exam-scores-tracker/
 
 The goal is to maintain sorted lists of times and scores, along with prefix sums for efficient range sum queries. We use binary search to find the range of indices that fall within the query time range.
 
-![Visualization showing sorted times with prefix sums for range queries]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3531/en.md b/explanations/3531/en.md
@@ -15,7 +15,6 @@
 
 The goal is to efficiently check for each building whether it has neighbors in all four directions. We group buildings by their x and y coordinates, then sort each group to quickly check for the existence of buildings in each direction.
 
-![Visualization showing a covered building with neighbors in all four directions]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3702/en.md b/explanations/3702/en.md
@@ -15,7 +15,6 @@
 
 The goal is to find the longest subsequence with non-zero XOR. If the entire array has non-zero XOR, we can take all elements. Otherwise, we need to remove at least one element to make the XOR non-zero.
 
-![Visualization showing XOR operation and subsequence selection]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3703/en.md b/explanations/3703/en.md
@@ -15,7 +15,6 @@
 
 The goal is to use a stack-like structure that groups consecutive characters. When we see k closing parentheses following at least k opening parentheses, we remove them. This simulates the repeated removal process efficiently.
 
-![Visualization showing stack-based removal of k-balanced substrings]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3705/en.md b/explanations/3705/en.md
@@ -15,7 +15,6 @@
 
 The goal is to aggregate order data by customer, calculate peak hour percentages, rating statistics, and filter customers who meet all four criteria. We use SQL aggregation functions with conditional logic to compute the required metrics.
 
-![Visualization showing customer order patterns with peak hours highlighted]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3708/en.md b/explanations/3708/en.md
@@ -15,7 +15,6 @@
 
 The goal is to scan through the array and track the longest contiguous sequence that follows the Fibonacci property. We maintain a running length and extend it when the current element equals the sum of the previous two.
 
-![Visualization showing Fibonacci subarray with each element being the sum of previous two]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3709/en.md b/explanations/3709/en.md
@@ -15,7 +15,6 @@
 
 The goal is to maintain sorted lists of times and scores, along with prefix sums for efficient range sum queries. We use binary search to find the range of indices that fall within the query time range.
 
-![Visualization showing sorted times with prefix sums for range queries]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3713/en.md b/explanations/3713/en.md
@@ -8,14 +8,13 @@
 
 * **Input Size:** The string `s` can have up to 1000 characters, consisting of lowercase English letters.
 * **Time Complexity:** O(n^2) - We check all possible substrings by fixing start and end positions, and use a Counter to track character frequencies in O(1) per operation.
-* **Space Complexity:** O(n) - In the worst case, we store up to 26 distinct characters in the Counter.
+* **Space Complexity:** O(1) - The Counter can hold at most 26 distinct characters (lowercase English letters), regardless of string length.
 * **Edge Case:** If all characters are the same, the entire string is balanced with length n.
 
 **1.2 High-level approach:**
 
 The goal is to check all possible substrings and find the longest one where all distinct characters have equal frequency. We use a Counter to track character counts as we extend substrings.
 
-![Visualization showing balanced substring with equal character frequencies]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3714/en.md b/explanations/3714/en.md
@@ -15,7 +15,6 @@
 
 The goal is to use prefix sums to efficiently find substrings where character frequencies are balanced. For a balanced substring S[i:j], the differences in prefix counts must be equal. We use hash maps to track the first occurrence of each (difference pattern, remaining count) combination.
 
-![Visualization showing prefix sum differences for balanced substrings]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3719/en.md b/explanations/3719/en.md
@@ -15,7 +15,6 @@
 
 The goal is to check all possible subarrays and find the longest one where distinct even numbers equal distinct odd numbers. We use sets to efficiently track distinct values as we extend subarrays.
 
-![Visualization showing subarray with balanced distinct even and odd numbers]
 
 **1.3 Brute force vs. optimized strategy:**
 
diff --git a/explanations/3720/en.md b/explanations/3720/en.md
@@ -15,7 +15,6 @@
 
 The goal is to build the answer character by character, always choosing the smallest valid character at each position. We use backtracking to explore possibilities, but prune branches that cannot lead to a valid answer.
 
-![Visualization showing backtracking tree with pruning for lexicographic ordering]
 
 **1.3 Brute force vs. optimized strategy:**
 
@@ -48,14 +47,14 @@ We call `backtrack([], cnt, False)` to start building the permutation.
 
 **2.3 Trace Walkthrough:**
 
-| Step | pos | char tried | big   | path          | Action               |
-| ---- | --- | ---------- | ----- | ------------- | -------------------- |
-| 1    | 0   | 'a'        | False | ['a']         | Skip (a < 'b')       |
-| 2    | 0   | 'b'        | False | ['b']         | Continue (b == 'b')  |
-| 3    | 1   | 'a'        | False | ['b','a']     | Skip (ba < bba)      |
-| 4    | 1   | 'b'        | False | ['b','b']     | Continue (bb == bb)  |
-| 5    | 2   | 'a'        | False | ['b','b','a'] | Skip (bba not > bba) |
-| 6    | 2   | 'c'        | True  | ['b','c']     | Found! Return "bca"  |
+| Step | pos | char tried | big   | path          | Action                    |
+| ---- | --- | ---------- | ----- | ------------- | ------------------------- |
+| 1    | 0   | 'a'        | False | -             | Skip (a < 'b')            |
+| 2    | 0   | 'b'        | False | ['b']         | Continue (b == 'b')       |
+| 3    | 1   | 'a'        | False | -             | Skip (a < 'b')            |
+| 4    | 1   | 'b'        | False | -             | Skip (count=0, no more b) |
+| 5    | 1   | 'c'        | True  | ['b','c']     | Continue (c > 'b'), big=True |
+| 6    | 2   | 'a'        | True  | ['b','c','a'] | Found! Return "bca"       |
 
 At step 6, we find that "bca" > "bba", so we return it.
 
diff --git a/explanations/3724/en.md b/explanations/3724/en.md
@@ -15,7 +15,6 @@
 
 The goal is to choose which element from nums1 to append, then minimize the total adjustment cost. For the chosen element, it must match both its original position in nums2 and the last position in nums2. We find the optimal value (median) that minimizes the total adjustment for this element.
 
-![Visualization showing transformation with one element being appended and adjusted]
 
 **1.3 Brute force vs. optimized strategy:**
 
@@ -50,8 +49,8 @@ We try each possible position j to append.
 
 | Step | j   | nums1[j] | nums2[j] | last_target | current | median | adjust_cost | total | res |
 | ---- | --- | -------- | -------- | ----------- | ------- | ------ | ----------- | ----- | --- |
-| 1    | 0   | 2        | 1        | 3           | 2-1=1   | 2      |             | 2-2   | +   | 1-2 | + | 3-2 | =2 | 1+2+1=4  | 4 |
-| 2    | 1   | 8        | 7        | 3           | 2-1=1   | 7      |             | 8-7   | +   | 7-7 | + | 3-7 | =8 | 1+8+1=10 | 4 |
+| 1    | 0   | 2        | 1        | 3           | 2-1=1   | 2      | abs(2-2)+abs(1-2)+abs(3-2)=2 | 1+2+1=4  | 4 |
+| 2    | 1   | 8        | 7        | 3           | 2-1=1   | 7      | abs(8-7)+abs(7-7)+abs(3-7)=8 | 1+8+1=10 | 4 |
 
 At step 1, we find the optimal cost is 4: adjust 2 to 2 (median), then adjust to 1 at position 0 and 3 at the end.
 
diff --git a/explanations/3728/en.md b/explanations/3728/en.md
@@ -15,7 +15,6 @@
 
 The goal is to efficiently find all subarrays [l, r] where capacity[l] == capacity[r] and capacity[l] equals the sum of elements between l and r. We use prefix sums to quickly calculate interval sums, and a hash map to count matching left endpoints for each right endpoint.
 
-![Visualization showing a stable subarray with equal boundary elements and interior sum]
 
 **1.3 Brute force vs. optimized strategy:**
 
@@ -49,19 +48,21 @@ We iterate through each position r from 0 to n-1, processing it as a potential r
 **2.3 Trace Walkthrough:**
 
 | Step | r   | capacity[r] | Add to map? | required_prefix | Check map | res |
-| ---- | --- | ----------- | ----------- | --------------- | --------- | --- |
-| 0    | 0   | 9           | No (r < 2)  | -               | -         | 0   |
-| 1    | 1   | 3           | No (r < 2)  | -               | -         | 0   |
-| 2    | 2   | 3           | Yes (l=0)   | 9 - 3 = 6       | (9, 9)?   | 0   |
-| 3    | 3   | 3           | Yes (l=1)   | 12 - 3 = 9      | (3, 9)?   | 0   |
-| 4    | 4   | 9           | Yes (l=2)   | 15 - 9 = 6      | (9, 6)?   | 1   |
+| ---- | --- | ----------- | ----------- | ---------------- | --------- | --- |
+| 0    | 0   | 9           | No (r < 2)  | -                | -         | 0   |
+| 1    | 1   | 3           | No (r < 2)  | -                | -         | 0   |
+| 2    | 2   | 3           | Yes (l=0)   | prefix[2]-3=12-3=9 | (3, 9)? | 0   |
+| 3    | 3   | 3           | Yes (l=1)   | prefix[3]-3=15-3=12 | (3, 12)? | 1   |
+| 4    | 4   | 9           | Yes (l=2)   | prefix[4]-9=18-9=9 | (9, 9)? | 2   |
 
-At step 4, we find that capacity[0] = 9 and prefix[1] = 9, which matches (9, 6) after rearranging. The subarray [0, 4] is stable: 9 == 9 and 9 == 3+3+3.
+At step 3, we find that capacity[1] = 3 and prefix[2] = 12, which matches (3, 12). The subarray [1, 3] = [3, 3, 3] is stable: 3 == 3 and 3 == 3 (sum of middle elements).
+
+At step 4, we find that capacity[0] = 9 and prefix[1] = 9, which matches (9, 9). The subarray [0, 4] = [9, 3, 3, 3, 9] is stable: 9 == 9 and 9 == 3+3+3.
 
 **2.4 Increment and Loop:**
 
 For each r >= 2, we add index r-2 to the map with key (capacity[r-2], prefix[r-1]), then check if any previous left endpoint matches our requirements.
 
 **2.5 Return Result:**
 
-After processing all positions, we return `res = 2`, representing the two stable subarrays: [9, 3, 3, 3, 9] and [3, 3, 3].
+After processing all positions, we return `res = 2`, representing the two stable subarrays: [3, 3, 3] (found at step 3) and [9, 3, 3, 3, 9] (found at step 4).
diff --git a/solutions/3705/01.py b/solutions/3705/01.py
@@ -10,8 +10,8 @@
         COUNT(*) AS total_orders,
         SUM(
             CASE 
-                WHEN HOUR(order_timestamp) BETWEEN 11 AND 13 
-                     OR HOUR(order_timestamp) BETWEEN 18 AND 20 
+                WHEN TIME(order_timestamp) BETWEEN '11:00:00' AND '14:00:00'
+                     OR TIME(order_timestamp) BETWEEN '18:00:00' AND '21:00:00'
                 THEN 1 
                 ELSE 0 
             END
@@ -26,8 +26,8 @@
         COUNT(*) >= 3
         AND SUM(
             CASE 
-                WHEN HOUR(order_timestamp) BETWEEN 11 AND 13 
-                     OR HOUR(order_timestamp) BETWEEN 18 AND 20 
+                WHEN TIME(order_timestamp) BETWEEN '11:00:00' AND '14:00:00'
+                     OR TIME(order_timestamp) BETWEEN '18:00:00' AND '21:00:00'
                 THEN 1 
                 ELSE 0 
             END

Original file line number	Diff line number	Diff line change
`@@ -10773,7 +10773,6 @@ https://leetcode.com/problems/design-exam-scores-tracker/`
`10773`	`10773`
`10774`	`10774`	`The goal is to maintain sorted lists of times and scores, along with prefix sums for efficient range sum queries. We use binary search to find the range of indices that fall within the query time range.`
`10775`	`10775`
`10776`		`-![Visualization showing sorted times with prefix sums for range queries]`
`10777`	`10776`
`10778`	`10777`	`1.3 Brute force vs. optimized strategy:`
`10779`	`10778`
Original file line number	Diff line number	Diff line change
`@@ -15,7 +15,6 @@`
`15`	`15`
`16`	`16`	`The goal is to efficiently check for each building whether it has neighbors in all four directions. We group buildings by their x and y coordinates, then sort each group to quickly check for the existence of buildings in each direction.`
`17`	`17`
`18`		`-![Visualization showing a covered building with neighbors in all four directions]`
`19`	`18`
`20`	`19`	`1.3 Brute force vs. optimized strategy:`
`21`	`20`