Summary
The checker for algorithmic problem 64 (algorithmic/problems/64/chk.cc, lines 54-60) intends to read the numeric target value T as a token:
// Read n and T (T may exceed 64-bit, read as token then parse u128)
long long n_ll = inf.readLong(1LL, 1000LL, "n");
size_t n = (size_t)n_ll;
string Ttok = inf.readToken("T"); // line 57
u128 T;
if (!parse_u128_str(Ttok, T)) {
quitf(_fail, "Invalid T token: '%s'", Ttok.c_str());However, in testlib the single-string overload of readToken interprets its first argument as a pattern, not a variable name (testlib.h):
/* The same as "readToken()", but ensures that token matches to given pattern. */
std::string readToken(const std::string &ptrn, const std::string &variableName = "");
So line 57 requires the input token to match the literal regex T. Every official input for problem 64 has a decimal number here, which cannot match, so the checker fails while parsing the official input — before it ever reads the contestant's output (the first ouf reads only appear at lines 71-85).
Effect
Problem 64 is effectively unjudgeable: every submission fails at the same point regardless of content. Archived results consistent with this: multiple models' runs show 0.0 on this problem.
Suggested fix
Use the no-argument overload, or pass the field name in the variableName position:
string Ttok = inf.readToken();
// or: keep a name for diagnostics without a pattern constraint
Summary
The checker for algorithmic problem 64 (
algorithmic/problems/64/chk.cc, lines 54-60) intends to read the numeric target valueTas a token:However, in testlib the single-string overload of
readTokeninterprets its first argument as a pattern, not a variable name (testlib.h):So line 57 requires the input token to match the literal regex
T. Every official input for problem 64 has a decimal number here, which cannot match, so the checker fails while parsing the official input — before it ever reads the contestant's output (the firstoufreads only appear at lines 71-85).Effect
Problem 64 is effectively unjudgeable: every submission fails at the same point regardless of content. Archived results consistent with this: multiple models' runs show 0.0 on this problem.
Suggested fix
Use the no-argument overload, or pass the field name in the
variableNameposition:string Ttok = inf.readToken(); // or: keep a name for diagnostics without a pattern constraint