Quantum data encoding determines how a classical dataset becomes a quantum state and often sets the practical limits of a circuit before the algorithm itself is designed. This guide compares basis, angle, amplitude, and direct qubit encoding, then provides a repeatable method for estimating qubit requirements, circuit depth, state-preparation cost, and hardware fit.
Overview
A quantum processor does not accept a spreadsheet, image, or feature vector directly. Classical values must first be mapped to qubit states through gates and measurements. That mapping is called quantum data encoding, or feature encoding in quantum machine learning.
There is no universally best method. The right choice depends on the number and type of features, whether the data is binary or continuous, the available qubit count, the error characteristics of the target hardware, and whether the workflow is intended for classification, similarity estimation, optimization, or another task.
| Method | Typical qubit requirement | Data format | Preparation and depth | Common fit |
|---|---|---|---|---|
| Basis encoding | Usually one qubit per binary feature or bit | Binary, categorical after encoding, or discretized values | Often shallow for fixed bit strings | Combinatorial states, binary optimization, discrete inputs |
| Angle encoding | Often one qubit per feature per feature map layer | Scaled continuous or bounded numerical features | Usually modest; repeated layers increase depth | Variational classifiers and small numerical datasets |
| Amplitude encoding | Approximately log2(N) qubits for N amplitudes | Normalized real or complex vectors | State preparation can be expensive and deep | Compact theoretical representations and selected simulation studies |
| Direct qubit encoding | Depends on the physical or logical representation | Problem variables mapped directly to qubit states | Varies by mapping and constraints | Optimization, search, and problem-specific circuits |
The table shows why qubit count alone is an incomplete measure. Amplitude encoding can use fewer qubits than angle encoding, but preparing the required state may add substantial gates. Conversely, angle encoding may use more qubits while remaining easier to test on a simulator or early hardware workflow.
How to estimate
Use the following process before selecting a quantum software framework or hardware target.
1. Define the usable feature vector
Start with the data that will actually enter the circuit, not the raw dataset. Remove identifiers, decide how missing values will be handled, and document categorical encoding. Let d represent the number of resulting features and N represent the length of a vector to be loaded as amplitudes.
2. Estimate qubits
- Basis encoding: count the bits needed to represent each input. If a record contains b binary values, a simple mapping requires about b qubits.
- Angle encoding: begin with roughly one qubit per feature. If features are loaded in multiple rotations or feature-map layers, the qubit count may stay constant while circuit depth grows.
- Amplitude encoding: estimate ceil(log2(N)) qubits for a vector with N entries, padding the vector when N is not a power of two. This estimate does not include ancillas that a particular state-preparation routine may require.
- Direct qubit encoding: derive the count from the problem representation. For example, a binary decision variable may map to one qubit, while a variable with several discrete states may require multiple qubits or a one-hot construction.
3. Estimate circuit depth
Separate three components: data loading, the algorithm or ansatz, and measurement-related repetitions. For angle encoding, count the rotation gates per feature and add entangling layers. For basis encoding, count the gates needed to change the initial state into the desired bit pattern. For amplitude encoding, treat state preparation as its own circuit and inspect the transpiled result for the chosen backend rather than relying only on the abstract circuit.
4. Estimate execution burden
Quantum programs generally require repeated measurements, often called shots, to estimate expectation values or class probabilities. A useful planning quantity is:
Approximate workload = circuits per training step × shots per circuit × number of training steps.
This is not a price formula. It is a repeatable way to compare experimental designs. A circuit with fewer qubits may still require more work if it has many feature-map layers, parameter updates, or measurement settings.
5. Test the smallest faithful version
Build a reduced dataset and compare the encoding on a local quantum circuit simulator before using cloud quantum computing or hardware. Check state preparation, measurement distributions, gradient behavior where relevant, and the effect of noise. A simulator can validate logic and expose scaling problems, but its runtime and memory behavior should not be treated as a direct forecast of hardware performance.
Inputs and assumptions
A defensible encoding estimate records more than feature count. Capture these inputs in a short design note:
- Feature type: binary, ordinal, categorical, continuous, sparse, or structured.
- Scaling rule: for angle encoding, specify the interval used for rotations and how outliers are handled.
- Vector dimension: for amplitude encoding, record the padded length and normalization rule.
- Ancilla allowance: include any auxiliary qubits required by the selected state-preparation or oracle construction.
- Re-uploading plan: note whether the same features are inserted across several layers.
- Hardware assumptions: distinguish ideal simulation from a device with limited connectivity, gate errors, readout errors, or restricted native gates.
- Objective: define whether success means predictive accuracy, feasibility of an optimization circuit, reduced resource use, or simply a reproducible baseline.
Normalization is particularly important for amplitude encoding. A vector must represent valid probability amplitudes, so its entries need to be scaled according to the state-preparation convention. Scaling changes the representation and should be fitted consistently between training and test data. It also does not make state preparation free: the compact qubit count can conceal a costly loading procedure.
For angle encoding, feature scaling affects the meaning of rotations. Large or unbounded values should not be passed into a rotation gate without a deliberate transformation. Periodic rotations can also make very different classical values appear similar, so test the chosen range against the problem rather than assuming that more rotation range is better.
Worked examples
Example 1: A binary optimization record
Suppose each candidate solution contains 12 binary decisions. A straightforward basis encoding uses approximately 12 qubits, with the computational basis state representing the decision string. This is a reasonable starting point when the algorithm operates directly on binary assignments. The estimate should then be increased if constraint ancillas, penalty terms, or additional registers are needed.
Example 2: A small numerical classifier
Consider six continuous features scaled to a defined rotation interval. A first angle-encoding experiment can use six data qubits and one rotation per feature. If the feature map is repeated three times, the qubit estimate may remain six, but the rotation and entangling depth increases. The practical comparison should therefore report both six qubits and the transpiled depth after compilation for the intended backend.
Example 3: A normalized vector
A vector with 16 entries can, in principle, be represented with four amplitude qubits because 24 equals 16. A vector with 10 entries can be padded to 16 and still use four qubits. However, the padding rule, normalization, state-preparation circuit, ancillas, and compiled depth must be recorded. If the preparation circuit dominates the workload, the apparent qubit advantage may not produce a better end-to-end experiment.
These examples illustrate the central decision: compare complete circuits, not encoding labels. A useful experiment keeps the dataset split, optimizer, measurement budget, and evaluation metric fixed while changing only the encoding and any unavoidable resource requirements.
When to recalculate
Revisit the estimate whenever the dataset changes, features are added or removed, categorical variables are re-encoded, or preprocessing alters vector length or scale. Recalculate before moving from a simulator to hardware, because connectivity, native gates, compilation, noise, and available qubits can change the practical circuit substantially.
Update the design after changing SDK APIs, state-preparation techniques, transpiler settings, feature-map templates, or backend capabilities. Framework examples in Qiskit, Cirq, and PennyLane can evolve, so confirm current syntax and inspect the compiled circuit rather than copying an older example unchanged.
For an actionable review, keep a small encoding worksheet with: feature count, encoding method, qubits, ancillas, normalization rule, logical depth, compiled depth, entangling-gate count, shots, circuits per iteration, and the result metric. Recalculate those fields whenever the inputs or implementation target changes. If amplitude preparation dominates, test angle or basis encoding as a baseline. If angle encoding exceeds the hardware budget, reduce features, reuse features across layers carefully, or redesign the classical preprocessing. This makes quantum data encoding a measurable engineering decision rather than a choice based only on the smallest theoretical qubit count.
