You do not read a Codeforces statement like a short story. You mine a contract: what tokens come in, what tokens go out, how big they can be, and what the judge actually scores.
The English is a model. The Input / Output / Constraints / Notes blocks are the spec. Experts finish those before they finish Farmer John's cows. If you invent an algorithm from the first paragraph, you will solve a different problem than the one on the scoreboard.
time limit per test: 2 seconds
memory limit per test: 256 megabytes
Input
The first line contains a single integer t (1 ≤ t ≤ 10^4) — the number of test cases.
The first line of each test case contains two integers n and k (1 ≤ n ≤ 2·10^5, 1 ≤ k ≤ 10^9)…
It is guaranteed that the sum of n over all test cases does not exceed 2·10^5.
Output
For each test case, print YES if … and NO otherwise.
You may print each letter in any case (YES, yes, YeS are all accepted).
Example
Input
3
4 2
1 3 2 4
1 1
5
3 5
1 2 3
Output
YES
YES
NO
Note
In the first test, one valid answer is to swap indices 2 and 3.Read in this order, every time:
1. Time / memory. Confirms the budget you already trained in Thinking in Constraints.
2. Input shape. Is there a t? Does each case start with n, then a line of n integers, or n lines of pairs? Missing a line is a WA that looks like a wrong idea.
3. The sum-of-n line. t ≤ 10⁴ and n ≤ 2·10⁵ together do not mean 10⁴ × 2·10⁵ work is legal. The guarantee sum n ≤ 2·10⁵ is the real bound. Resetting an n = 2·10⁵ array every test without that guarantee is a TLE; not resetting it with the guarantee is a WA.
4. Output. YES/NO? A number? n lines? Any construction, or the minimum? This is where people solve the wrong problem.
5. Samples. They are tests, not the spec. They show the I/O layout and kill the dumbest misreads. They do not cover overflow, n = 1, or t > 1.
6. Notes. CF notes often contain the intended construction, a worked sample, or the sentence 'it can be shown that an answer always exists if…' — that sentence is an algorithm hint, not flavor.
Name the output class out loud. It changes the code you write:
- Unique value. Minimum length, count of ways, the lexicographically smallest string. There is one right answer. Diff the sample exactly, including spaces and newlines.
- YES / NO (or Yes / No). Read the Output section for case. CF often allows any case; AtCoder usually wants the sample's case exactly. Do not invent Y / N.
- Any valid. 'Print any array that satisfies…' — a checker, not a unique token stream. Do not waste time matching the sample construction if yours is legal.
- All solutions / count. Different problem. n! listings vs n! mod 10⁹+7 are not the same task.
- Interactive. You print queries, flush, read answers. Treating it as a batch problem hangs the judge.
USACO bronze statements add one more trap: the first line is often N, and you write to a file. On the USACO guide / Podium-style judges you may still see stdin. Read the I/O paragraph anyway — the rest of the extraction is identical.
Checks 0/3