Skip to content

Fix #185: align problem 213 checker with the documented output format - #188

Merged
joyemang33 merged 1 commit into
FrontierCS:mainfrom
whuang369:fix/185-problem-213-checker
Sep 10, 2026
Merged

Fix #185: align problem 213 checker with the documented output format#188
joyemang33 merged 1 commit into
FrontierCS:mainfrom
whuang369:fix/185-problem-213-checker

Conversation

@whuang369

Copy link
Copy Markdown
Contributor

Fixes #185.

Problem

The statement for problem 213 specifies three integers per operation (l r direction), and the sample output plus every answer file in testdata/ use that format. But algorithmic/problems/213/chk.cc read only two integers per operation:

x=ouf.readInt(); y=x+m-1; z=ouf.readInt();

It derived the right endpoint from the segment length and then consumed r as the direction. For a statement-compliant l r d, the direction check (z!=0 && z!=1) fails on the first ordinary operation, so the checker quit with wrong answer Your answer is not legal before validating the sequence or computing a score. No submission following the published specification could score.

This was verified against the repository's own data: compiling the pre-fix checker and feeding it testdata/{1,2,3}.ans as the contestant output rejected all three.

Changes

  • chk.cc — read l, r and d as three separate integers. The existing interval-length (r - l + 1 == x), bounds and direction validation is unchanged, so it now actually enforces the documented contract.
  • testdata/1.ans — was 3 / 1 / 1 2: segment length 3 for an input with n = 2, and an operation with no direction field. Replaced with the valid 2 / 1 / 1 2 0.
  • statement.txt — the prose claimed x and m share the first line while the sample printed them on separate lines. Aligned the prose to the sample, since the sample and all three answer files already agreed. Also spelled out the r - l + 1 = x and 1 <= l <= r <= n constraints that the checker enforces.
  • config.yaml — time limit 2s -> the documented 5s.

Scoring logic, subtasks and the 23n / 230n thresholds are untouched.

Verification

Checker built against algorithmic/judge/include/testlib.h.

Repository answer files, before vs. after:

Case Before After
1.ans wrong answer Your answer is not legal 1.0 (1 op)
2.ans wrong answer Your answer is not legal 0.9577 (31754 ops)
3.ans wrong answer Your answer is not legal 0.9952 (23987 ops)

The statement's own worked example (n = 5, 4 2 3 5 1) now scores 1.0.

Illegal outputs are still rejected, confirming the validation was not loosened:

  • interval length != x -> Your answer is not legal
  • r > n -> Your answer is not legal
  • direction not in {0, 1} -> Your answer is not legal
  • valid ops that do not sort the permutation -> Your answer is wrong

End-to-end, the real submission at algorithmic/solutions/213/gpt5.cpp went from rejected on all three cases to scoring 1.0 / 0.6299 / 0.6305. Every model solution in algorithmic/solutions/213/ emits the three-integer l r d form, which independently corroborates that the statement, not the checker, held the correct specification.

🤖 Generated with Claude Code

…put format

The statement specifies three integers per operation (l r direction), and
the sample plus every answer file use that format, but chk.cc read only
two: `x=ouf.readInt(); y=x+m-1; z=ouf.readInt();`. It derived the right
endpoint from the segment length and then consumed `r` as the direction,
so the first ordinary operation was misparsed and any statement-compliant
submission was rejected before scoring. The repo's own testdata answers
failed against it.

- chk.cc: read l, r and d as three separate integers, keeping the existing
  interval-length, bounds and direction validation.
- testdata/1.ans: replace an invalid answer (x=3 for n=2, and an operation
  with no direction) with `2 / 1 / 1 2 0`.
- statement.txt: describe x and m on separate lines, matching the sample
  and the answer files, and spell out the l/r/d constraints.
- config.yaml: raise the time limit to the documented 5s.

Verified: all three testdata answers now score (1.0, 0.9577, 0.9952), the
statement's sample scores 1.0, and illegal outputs (wrong interval length,
r > n, direction not in {0,1}) are still rejected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@joyemang33
joyemang33 merged commit ad37be5 into FrontierCS:main Sep 10, 2026
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Problem 213: Checker output format is inconsistent with the statement and test answers

2 participants