Quantum Maths for Performance

Most writing about quantum computing sells a machine you cannot buy, for a problem you do not have. The useful story is older and quieter. The mathematics that describes quantum systems (Hilbert spaces, linear operators, tensor products, spectral decomposition, interference) already solves performance problems on classical hardware, in software architecture, and in how people decide.

This guide separates that maths from the hardware hype. It is written for technical founders and engineering managers who ship products, not for people shopping for a qubit. If you are choosing a data architecture instead, start with our companion on three PostgreSQL moves that still pay in 2026.

What pure quantum maths actually is

A Hilbert space is a complete inner-product space. In practice it is a vector space where you can measure angles and lengths, and where infinite series of approximations still land on a real state. Quantum theory uses that space to hold a system before anyone looks.

Superposition is not mysticism. It is a linear combination. If two basis states are allowed, the system can sit in a|0> + b|1> until a measurement projects it onto one of them. The coefficients are amplitudes. Squared, they become probabilities. Interference is what happens when those amplitudes add before anyone squares them: paths can cancel, not only accumulate.

Three operators do most of the work:

• Linear operators map states to states. Unitary ones preserve length (reversible evolution). Projectors implement measurement.
• Tensor products compose systems. Two small spaces become one large space. That is why many-body problems explode, and why tensor networks exist as a compression trick.
• The spectral theorem says a well-behaved operator is a sum of eigenvalues times projections. Diagonalise it and you have the natural modes of the system: energy levels in physics, principal components in data, Laplacian eigenvectors on a graph.

You do not need a qubit to use any of this. You need a representation where the expensive correlations stay local, and a measurement (a query, a click, a sensor reading) that you apply on purpose rather than by accident.

Mind: quantum cognition, not quantum brains

Quantum cognition applies the probability rules of quantum theory to judgment, without claiming that neurons compute on qubits. Jerome Busemeyer and Emmanuel Pothos have spent two decades showing that classical Kolmogorov probability struggles with order effects, the conjunction fallacy, and the disjunction effect, while a Hilbert-space model of belief handles them as incompatible questions: asking A first rotates the mental state, so P(B then A) is not P(A then B).

A 2022 Annual Review of Psychology paper and a 2025 overview in Psychonomic Bulletin & Review collect the evidence. The claim is modest and useful: some mental measurements do not commute. That is an operator fact, not a physics of consciousness. Penrose-style quantum microtubules are a different argument and not required here.

What a product team can do with that:

• Question order is a measurement order. Checkout, onboarding, and survey flows that ask the high-stakes question first lock a state that later questions cannot recover. Reverse the order in a test and you are not "randomising copy". You are changing which projector fires first.
• Recommendations sit in superposition until the click. Ranking a catalogue as a single collapsed list too early throws away interference between compatible options. Keep a scored distribution longer; measure at the moment of choice.
• A/B tests are not always compatible observables. Two variants that ask the user to hold contradictory frames ("save money" versus "look premium") can interfere. Sequential testing, or mutually exclusive cohorts, is the honest measurement.

This is how we think about interactive flows on app builds: the interface is a sequence of measurements. Order is architecture.

Technology: spectra, graphs, and tensor networks

The same spectral theorem that gives energy eigenstates gives you PageRank (a dominant eigenvector), graph cuts (Laplacian Fiedler vector), and principal components. If your system is a network of pages, users, or machines, the cheap global summary is often an eigenspace, not a full traversal.

Tensor networks, born in condensed-matter physics, are the compression layer. A matrix product state (also called a tensor train) stores a high-dimensional array as a chain of small tensors. When correlations are local, the bond dimension stays small and memory scales linearly with dimension instead of exponentially. Recent work on quantum-inspired PDE solvers and material simulation shows exponential memory cuts on smooth fields, and an entanglement barrier when shocks or long-range correlations appear. That limitation is the point: the maths tells you when the trick will fail, which is more valuable than a benchmark that only shows the win.

Quantum-inspired optimisation (QAOA-style mixing on a classical annealer, tensor-network contraction for combinatorial structure) belongs in the same drawer as simulated annealing: use it when the cost landscape has a known algebraic shape, not as a default over a well-indexed SQL query.

Software: represent state so correlations stay cheap

Most slow software is not missing a compiler flag. It is representing a high-dimensional state in a way that forces the machine to touch everything.

• Tensor trains and SVD compress recommendation matrices, simulation grids, and configuration spaces when the data has low rank. PCA is the spectral theorem with a Gaussian hat on.
• The FFT is the classical cousin of quantum phase estimation: a change of basis into the eigenmodes of a circulant operator. If your bottleneck is a convolution, change basis before you throw GPUs at the naive form.
• Deferred evaluation is an uncollapsed state. Lazy graphs, query planners, and CRDTs delay measurement until a read forces it. Collapse early and you pay for work nobody asked for.
• Grover thinking is a complexity habit, not an algorithm you will ship. Unstructured search costs on the order of the square root of the space if you can mark and interfere. On classical hardware that still means: do not do unstructured search. Build a structure (an index, a hash, a filter) so the "oracle" is cheap.

For a Melbourne team building custom software, the design rule is simple. Model the state so the expensive correlations are local. Then the tensor-network story, the spectral story, and the database story are the same story. That is also why automation work that stuffs a giant unstructured prompt with the whole business is slower and worse than a small state machine with a measured retrieval step.

Hardware: your GPU already speaks this language

Tensor cores exist because deep learning is bilinear maps. The same silicon that multiplies attention heads will multiply a tensor-train core or an SVD step. You do not wait for a quantum foundry to buy that performance. You wait for a representation that fits in SRAM before it spills to HBM, and HBM before it spills to DRAM. That hierarchy is decoherence in slow motion: each hop away from the register file costs fidelity (latency, energy, and the chance that the working set no longer fits).

SIMD is a batched superposition of data: one instruction, many amplitudes, a single measurement of the pipeline. Analog and photonic accelerators are the long bet for the same linear algebra, still research for production SaaS.

NISQ machines in 2026 are real devices with real noise. They are a fit for chemistry and materials simulation research, and for algorithm prototyping. They are not a fit for OLTP, CRMs, websites, or the booking systems we ship. Error-corrected logical qubits at a scale that beats a well-tuned classical solver on a business workload are not a 2026 delivery plan.

What quantum computers are not ready for

There is no quantum Postgres. There is no quantum checkout. Shor's algorithm threatens some public-key schemes on a timeline that crypto-agility teams already track; it does not make your product database faster. Grover's algorithm gives a quadratic cut on unstructured search, which a B-tree already beats by refusing to be unstructured.

If a vendor sells "quantum speedup" for a website, a SaaS, or a marketing engine, ask three questions: which Hilbert space, which operator, and which classical baseline did they beat after a competent engineer was allowed to index the data? If they cannot answer, you are buying a press release.

Use the maths now. Rent the machine later, if ever. If you want that applied to an actual product (state models, ranking, or a database that is slow for structural reasons) request a Discovery Session. We will tell you whether the bottleneck is representation, I/O, or a story someone sold you.

Quantum maths FAQs

Do I need a quantum computer to use this?

No. Hilbert spaces, tensor networks, spectral methods and quantum-cognition models all run on classical machines. A quantum computer is a different hardware bet, and it is not required for any of the performance moves in this article.

Is quantum cognition claiming the brain is a quantum computer?

No. It claims that some judgments are better modelled with quantum probability (non-commuting measurements, interference) than with classical probability. That is a model of data, not a claim about neuronal qubits.

What can a Melbourne software team apply this year?

Treat UX and forms as measurement order. Keep ranking distributions uncollapsed until the click. Use SVD, FFT and tensor-train style compression where the data is low rank. Fix database locality before you shop for exotic accelerators. See our PostgreSQL 2026 notes for the data layer.

How do we start on a live product?

Request a Discovery Session. Bring the slow path (a ranking, a simulation, a query, or a funnel that changes when you reorder questions). We will say whether the maths applies, or whether you need a plainer engineering fix first.