DIRECTORY.md (1)

96-97: New binary search entry looks consistent; consider md indentation to satisfy MD007.

The added “Maxruntime N Computers” entry and test link are aligned with existing structure and point to the correct test path. Markdownlint (MD007, ul-indent) is complaining about the indentation on these bullets, though, so if your CI enforces that rule you may want to tweak the leading spaces (or adjust the rule) to keep the linter green.

algorithms/search/binary_search/maxruntime_n_computers/README.md (1)

31-68: Tighten up typos and notation in the README.

The narrative matches the implemented algorithms, but there are a few small doc issues worth fixing:

• Line 43: rught → right in the midpoint formula.
• Line 46: “the target feasible” → “the target is feasible” (or similar).
• Lines 62–64: clean up the extra closing parentheses in O(n⋅logT) and in T = sum(batteries) // n), and be consistent about what n denotes (number of computers vs number of batteries).
• Line 68: os → is, and consider ending with a period.

These fixes will make the explanation crisper and avoid confusion for readers following the math.

algorithms/search/binary_search/maxruntime_n_computers/test_max_runtime.py (1)

1-38: Solid parameterized coverage for both implementations; minor DRY opportunity.

The test cases and expected values look correct for the problem definition, and validating both max_runtime and max_run_time_2 against the same scenarios is a nice consistency check.

If you want to reduce duplication, you could extract the shared case list to a module-level constant and reuse it in both @parameterized.expand(...) decorators.

algorithms/search/binary_search/maxruntime_n_computers/__init__.py (1)

4-73: Binary search + feasibility check implementation looks correct; small reuse/clarity tweaks optional.

Both max_runtime and max_run_time_2 correctly:

• Bound the search by sum(batteries) // n.
• Use the monotone feasibility check sum(min(b, t)) >= n * t.
• Handle the 0-minute baseline and converge to the maximum feasible runtime without off‑by‑one issues.

A couple of optional refinements you might consider:

• Reuse can_run_for inside max_run_time_2 instead of duplicating the usable >= mid * n logic to keep the feasibility condition in one place.
• If you care about micro-optimizations, you could short‑circuit the sum(min(...)) loops once the running total meets or exceeds n * target_time to avoid iterating the entire list for obviously feasible candidates.

Functionality-wise this is good to go.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro