Zach has reached his breaking point.

After years of reading problem statements, editorial writeups, and contestant code, he has formed a very strong opinion: one-letter variable names are a blight on the programming world. Everywhere he looks, he sees x, y, z, and the infamous loop trio i, j, and k. In Zach's mind, these tiny names lurk in the darkness of nested loops, just waiting for the chance to confuse someone at 3 a.m. during a contest.

Zach dreams of a brighter future, one where variables are named total_score, remaining_capacity, or number_of_dragons_in_line, instead of a single mysterious character that might mean "index", or "coordinate", or "temporary something Zach will never understand without reading 50 lines of code around it".

Nick, however, is not fully on board with this crusade.

Nick claims that one-letter names are sometimes perfectly reasonable. "If the variable is a simple loop counter," Nick says, "calling it horizontal_coordinate_of_query_point is just overkill. Sometimes x is exactly the right size for the job." This statement makes Zach visibly cringe, but Nick is stubborn. Years of mathematical training have conditioned him to view x and friends as natural, harmless, even elegant.

Unable to win the argument with pure rhetoric, Zach turns to data. If he can systematically scan through a collection of variable names and identify how many of them are one-letter "offenders", maybe he can show Nick just how widespread the problem really is. If the evidence is overwhelming, perhaps Nick will finally admit that this style is at least slightly hazardous to the average reader's sanity.

Your task is to assist Zach in this mission.

You are given several test cases. Each test case consists of a single variable name. Every variable name is a nonempty string of lowercase English letters. Zach wants you to decide, for each variable name, whether it is one of the dreaded one-letter names or something at least slightly more descriptive.

The rules Zach proposes are extremely simple:

• If the variable name has length exactly 1 (for example, x, y, or a), then it is considered a one-letter variable name, and Zach wants you to proudly report YES.
• If the variable name has length greater than 1 (for example, ab, zach, or nicklikeslongnames), then it is considered "unacceptable" by Zach's minimum standards, and you should output NO.

Nick insists that the classification should not depend on the exact letter chosen. Whether the variable is named x, q, or z, it should be judged only by length, not by content. Zach reluctantly agrees; for once, they both accept that the decision rule is simple and mechanical.

Your job is to read all the variable names, apply Zach's one-letter test, and print the result for each test case. In the end, Zach will have a neat list showing exactly which names fall into his personal "problematic" category. What he does with that list, and whether Nick changes his problem setting style as a result, is another story entirely.

Constraints

~1 \le numTests \le 10^4~

~1 \le |variableName| \le 50~

Input Specification

The first line contains a single integer, ~numTests~.

The next ~numTests~ lines each contain a single string ~variableName~ of lowercase letters.

Output Specification

Output ~numTests~ lines, one per test case. For a given test case, output YES if the variable name provided is a one-letter variable name. Otherwise, output NO.

Sample Input 1

4
thisisnotaonelettervariablename
thisisalsonotaonelettervariablename
t
n

Sample Output 1

NO
NO
YES
YES