State
Marking oracle over a domain
A check you can run in superposition that answers yes or no about each candidate in a domain of known size, together with whatever promise you hold about how many candidates it says yes to. The promise is not decoration: Grover's own paper assumes exactly one, and the schedule that finds it is fixed before the first query from the domain size alone, so a different promise is a different algorithm rather than a different parameter.
A state is an object you can be holding, named once so that two routes reaching the same thing are drawn as reaching the same thing. It says nothing about how you got here or where you can go next — that is entirely in the processes below.
This is a kind of
This state is not recorded as a kind of anything else. It stands on its own in the vocabulary.
Narrower kinds of this
No state in the vocabulary is recorded as a narrower kind of this one.
Records that are this object
Nothing in the catalogue has been joined to this state. That is a gap in the join rather than a claim that no such object exists; the shelf on /repository lists what is joined and what is not, with the reason.
Work that arrives here
No recorded process returns this. Either it is where a reader starts — a problem, a matrix, a machine — or it is an object this graph names and no route yet reaches.
Work that starts here
- Find the item a check accepts
Given a way to test candidates and nothing else — no order on the domain, no structure to exploit — return one candidate the test accepts, in fewer queries than looking at them all.
- Search by state discrimination
When one query can test a partial guess rather than a whole candidate, the answer is recovered by discriminating quantum states instead of by rotating amplitude. One query turns knowledge of positions into knowledge of of them, and the measurement that does it is the one that minimises the error — though a stage costs more than that one query, because the guess it produces has to be checked and repaired.