Quantum computing is usually introduced through physics — qubits, superposition and interference — and only later translated into software. That order works badly for programmers, because the gap between "a qubit can be in two states at once" and "here is how I run a circuit and read the result" is where most of the friction lives. MicroQuantum exists to close that gap in a language people already use, so that the interesting question becomes the algorithm rather than the plumbing.
Why quantum computing needs its own SDK
A quantum program is not an ordinary program with a different library attached. Its unit of work is a circuit: a sequence of gates applied to a register of qubits, ending in measurement. The state of those qubits during computation is a complex vector whose size doubles with every qubit, which means a 30-qubit register already carries just over a billion amplitudes. Anything that executes such a circuit must make deliberate choices about representation, and a library that hides those choices makes it impossible to reason about what happens when they stop being affordable.
MicroQuantum makes the representation visible. Quantum states, gates and circuits are first-class objects in the SDK, so the shape of a computation can be inspected, and the choice of simulation strategy belongs to the code rather than to a global setting.
Circuit representation and gates
Circuits are built programmatically rather than read from a declarative file. A circuit is constructed for a given number of qubits, gates are applied by index — a Hadamard on qubit 0, a controlled-NOT from qubit 0 to qubit 1 — and the finished object is handed to an executor. Because gates take effect in the order they are called, a program reads in the same order the computation happens, which removes a whole class of ordering mistakes.
Simulation and numerical behaviour
Execution in the current release is by simulation, and two families of local backend ship with the SDK. A statevector backend tracks the full amplitude vector and applies gates directly to it; it is exact, and its cost grows exponentially with qubit count. A density-matrix backend tracks the density matrix instead, which can also represent mixed states but costs roughly quadratically more memory for the same register.
Sampling adds a second layer of approximation on top of the simulator. Executing with a finite shot count draws outcomes at random from the theoretical distribution, so repeated runs disagree slightly — a 1024-shot Bell state gives counts near 512/512 rather than exactly that. This is expected sampling behaviour rather than numerical drift, and it is worth separating from the subtler question of whether the simulator faithfully represents the circuit it was given.
Execution architecture
MicroQuantum separates how a program is defined from how it runs. A circuit or algorithm is expressed with the core, turned into an execution plan describing how and where it should run, dispatched by a runtime against a configured backend, and answered with a typed result. The backend abstraction is the important seam: circuit construction never references a simulator directly, so adding an execution target means implementing the backend interface rather than restructuring the program.
Algorithms and experiments
Four algorithm families ship as working implementations. The Variational Quantum Eigensolver (VQE) and the Quantum Approximate Optimization Algorithm (QAOA) are hybrid methods: a quantum circuit prepares a candidate state while a classical optimizer searches for better parameters. Grover's algorithm addresses unstructured search with a quadratic reduction in query count, and quantum phase estimation recovers eigenvalues of a unitary operator — a primitive that underpins many larger algorithms.
A single execution answers one question, which is rarely the question being asked. The experiment layer exists for the case where the same program must run repeatedly under different conditions: parameter sweeps execute a circuit across a grid of parameter values, and each run is recorded so that the sweep can be reproduced and analysed rather than re-derived from memory.
Maturity and limitations
Version 1.1.0 is a published public release on PyPI, which means the package installs and pins — a real but modest guarantee. The SDK is presented as a developer preview. Execution is simulation-only, no quantum hardware backend is included, and individual capabilities continue to evolve between releases. Simulated results should be read as statements about algorithms under ideal conditions, not as predictions of hardware performance.
Conclusion
MicroQuantum is a usable, dependency-light way to develop quantum programs in Python: circuits are explicit objects, execution is separated from construction, and repeated runs are structured for analysis. Everything it reports is simulation output, so it answers questions about algorithms rather than about hardware, and it should be read that way.