PennyLane
Install
Install
  1. Blog/
  2. Quantum Computing/
  3. Choosing between QSP, QSVT, and GQSP

August 18, 2026

Choosing between QSP, QSVT, and GQSP

Emily Nobes

Emily Nobes

QSP. QFT. QPT. QSVT. QPE. QAE. GQSP. ACDC. LMNOP. 😮‍💨

Quantum is hard enough as it is. Parsing through a dictionary of (very similar) acronyms in the pursuit of tools can make it even more intimidating to take on work in the field. When some of those acronyms refer to techniques that also have very similar functionalities, or terms are used inconsistently, the challenge grows. Today we will explore three repeat culprits of this phenomenon: Quantum Signal Processing (QSP), the Quantum Singular Value Transformation (QSVT), and Generalized Quantum Signal Processing (GQSP). This family of techniques for performing spectral transformations of quantum operators boils down to techniques for applying a polynomial transformation to an operator, often referred to as "the grand unification of quantum algorithms". It is crucial we keep these tools in our pockets, but how exactly do we know which one to wield and when?

In a pinch, there are two questions to ask yourself when distinguishing between techniques: (1) is my operator a non-square matrix? and (2) am I dealing with a complex polynomial and/or a polynomial with indefinite parity?

If your answer is "yes" to question 1, QSVT is your best friend since it is uniquely capable of dealing with the singular value (as opposed to eigenvalue) nature of non-square matrix transformations.

If your answer is "no" to question 1 and "yes" to question 2, you will almost always be inclined to use GQSP, which can handle large, complex functions of indefinite parity with ease. QSP is typically capable of handling small, single-qubit problems but remains the structural foundation on which QSVT and GQSP build.

But why?

Same idea, different operators

Before we can start drawing lines between the methods, let us establish what characteristics they share. Each of these approaches takes a broadly similar path. An input state undergoes an interleaved series of rotations and signal parsing operations until, eventually, the desired transformation is achieved.

In all cases a general signal operator is employed to act as an oracle function that accepts an input state and manipulates it according to its amplitude at a given point. The goal of this operator is to, essentially, generate a raw, malleable state onto which the target function can be encoded. Put very simply, the oracle should direct diagonal and off-diagonal components to separate, simultaneous "paths" (this is somewhat analogous to a beamsplitter).

In the case of QSP and QSVT, the structure of the signal operator is identical. The columns of the operator are defined such that diagonal entries are unchanged in amplitude but the off diagonal entries are flipped. Taking a to be a value dictating the target parameter of the system, such as the eigenvalues of a molecule, this can be represented in matrix form as

\hat{W}(a)=\begin{bmatrix} a & i\sqrt{1-a^2}\\\\ i\sqrt{1-a^2} & a \end{bmatrix}.

In QSP and QSVT, we typically deal with block-encoded operators, in which the original operator matrix is embedded in a larger matrix to achieve unitarity. As such, we are not applying the polynomial transformation directly to our operator, but to a larger system containing our operator as a subsection.

GQSP takes a different approach. While block encoding is still a strategy used here, the signal processing operator directly targets the eigenvalues of the unitary. To do this, the signal operator takes the form

\hat{A}=\ket{0}\bra{0}\otimes I+\ket{1}\bra{1}\otimes U.

This implementation distinguishes the state by flagging each state with an eigenphase. So, rather than carrying out the 'splitting' at this stage, it invokes a relative phase that will act as a flag for the system to carry this out during subsequent operations.

Subsequent operations, you say? The next commonality is the use of phase factors to facilitate the function fitting process. A common analogy for these terms is to imagine them as knobs on a device, where each can be turned to tune the system toward the target polynomial. These phase factors essentially give the recipe for what rotations need to occur for a desired outcome to be achieved.

Again, we vary here. In the case of QSP and QSVT, the phase factors are simply implemented using R_Z-like, multi-qubit rotations. This invokes the cascaded operator

\hat{U}_{QSP}=\hat{R}_Z(\phi_0)\prod_{k=1}^d\hat{W}(a)\hat{R}_Z(\phi_k)

where \phi_k are phase factors.

In GQSP, the rotations are carried out via the application of arbitrary SU(2) rotation matrices of the form

R(\theta,\phi,\lambda)=\begin{bmatrix} e^{i(\lambda+\phi)}\cos(\theta) & e^{i\phi}\sin(\theta) \\\\ e^{i\lambda}\sin(\theta) & -\cos(\theta) \end{bmatrix}\otimes I.

Where \theta, \phi, and \lambda are all angles contributed by a polynomial's phase factors. We will briefly discuss some particulars about angle finding for these methods, but rest assured PennyLane can handle this for you using tools such as pennylane.poly_to_angles!

This operator replaces the R_Z gates in the signal processing operator and W(a) is replaced by a controlled unitary signal operator to yield the generalized signal processing operator

\hat{U}_{GQSP}=\left(\prod_{j=1}^d \hat{R}(\theta_j,\phi_j,0)\hat{A}\right)\hat{R}(\theta_0,\phi_0,\lambda).

In each case, the signal processing operator is then applied multiple times to the input state to achieve the desired signal processing outcome. For those interested, the previous beamsplitter-like 'splitting' steps dictate the interference behaviour that occurs here between sequential applications of the operator, eventually yielding the final, target outcome.

It still does not seem clear here, though, when the best time is to use each method. To continue working toward that, let us define when exactly we cannot use them.

Translating the constraints

If you have engaged with any resource that discusses QSP, you have certainly come across this list:

  • \deg(P) \le d and \deg(Q) \le d - 1.
  • P has parity d \bmod 2, and Q has parity (d - 1) \bmod 2.
  • |P|^2 + (1 - a^2)|Q|^2 = 1.

Where P is the target polynomial, Q is the complementary polynomial of P, and d is the number of times the signal processing operator is applied. These constraints represent the foundational viability criteria for our techniques du jour, and yet they are scarcely elaborated on or translated to an intuitive conclusion on what is and isn’t possible for each method. So, let's dive in.

  1. The depth condition

The first constraint in this infamous list tells us that the query depth d of the circuit (i.e., the number of times the signal processing operator is applied) dictates the maximum degree of the target polynomial. For example, if you apply the signal processing operator 20 times, the maximum degree of P(a) is 20. To flip this in the other direction, if we are targeting a polynomial of degree 20, we know we need to query the operator 20 times. Thus, the lower bound on our resources is defined by the degree of the function we are dealing with.

Q(a), the complementary function that arises to enforce the unitary nature of the signal processing operator, is also limited by the query depth of the circuit but is constrained to one lesser degree. This is simply due to the way in which these polynomials are iterated and can be summarized as

P_{new}(a)=aP(a)-(1-a^2)Q^\dagger(a)

and

Q_{new}(a)=aQ(a)+P^\dagger(a),

which arises from the structure of the signal processing operator shown above.

Algebraically, this constraint just has to be true.

  1. The parity condition

The second constraint can be summarized quite neatly: uniaxial rotations can only perform accurate transformations on functions with definite parity. In other words, since we are constrained to only rotations in the z-axis, P(a) must be either even or odd, nothing in between. Any other scenario simply cannot be accessed by a single-axis transformation. Also, if P(a) is even, Q(a) must be odd, and vice versa. This, of course, restricts the types of functions that can be processed using single passes of these techniques (jumping slightly ahead: it is possible to carry out sequential applications on parts of a function that have different parity, though at the cost of notably more resources).

  1. The norm condition

This constraint is the most straightforward of the collection. Essentially, to implement these methods, the amplitude of the target function cannot exceed 1. TL;DR: the target function’s amplitude must be bounded by 1. This is precisely where the "compensating" nature of Q(a) becomes apparent, since its contribution is dictated by the amount that |P(a)|^2 is less than 1.

What’s the difference?

Now that we understand the broad constraints on these methods, we can draw our first coarse but clear line in capability. Polynomials passed into QSP and QSVT must adhere to all 3 constraints, but GQSP is notably more flexible.

In discussions of spectral transformations, the angular degrees of freedom that we have access to are often analogized as 'knobs' that can be tuned to the angles required to encode the target function on the system. These are the phase factors we discussed previously. The actual values of these phase factors are strictly related to the characteristics of the target polynomial.

Recall the above definition of the signal processing operator used in the case of QSP and QSVT. Skipping the derivation (sorry, or you're welcome), we know the commutation relationships between the uniaxial rotation operators results in, essentially, a cancelation that renders the final polynomial symmetry expression P(-x)=(-1)^dP(x). This means that for even degrees it must be true that P(-x)=P(x) and for odd degrees P(-x)=-P(x). This fundamentally limits the parity, imposing the constraint we explored previously. In plain English, it would be impossible to construct a function of indefinite parity using this operator since the symmetry relationship must yield either an even or an odd result. There is a workaround, however, that requires the system to be split into four parts:

  1. The real and even component
  2. The real and odd component
  3. The imaginary and even component
  4. The imaginary and odd component

These components would then need to be combined using a Linear Combination of Unitaries (LCU) to reconstruct the desired polynomial. To see a case in which LCUs are required, check out the QSVT in Practice PennyLane demo, which can be compared to a non-LCU case such as the one in the Function Fitting using Quantum Signal Processing PennyLane demo.

GQSP, however, takes advantage of the extra degrees of freedom in the arbitrary SU(2) rotation operator to alleviate this constraint, as discussed. In this case, we are no longer bound to a single axis, meaning we can make rotations that do not commute and, therefore, do not cancel each other out. With the additional parameter axes that we gain in this approach, we can deal with the dimensionality of complex phase angles and are no longer constrained to a single, definite parity.

In the GQSP signal processing operator, a controlled unitary operation was also introduced to replace the signal operator used in QSP and QSVT. In doing this, the axial constraints mentioned in the description of the parity constraint are eliminated from the system, along with the parity constraint itself. So, in the case of GQSP, definite parity is not required. By allowing complex coefficients and not caring about parity, we have opened many doors!

Some additional, slight differences exist between the QSP/QSVT and GQSP constraints, though they are more subtle. For the depth condition, it is now true that the degree of both P(a) and Q(a) are bound by d rather than Q(a) being bound by d-1. The norm condition is also redefined as |P(a)|^2+|Q(a)|^2=1. These also increase the flexibility of this approach in comparison.

The Angle Finding Problem

One final, heavily shrouded aspect of spectral transformations is the angle finding step that determines the phase factors. The means by which we typically carry out angle finding differ between QSP and GQSP, though not necessarily due to the structure of the methods themselves. Broadly, QSP (and, consequently, QSVT) are able to apply accessible algebraic tools such as root finding methods to generate the polynomials from which their phase factors are extracted. GQSP, however, is limited in which tools it can use for angle finding due to, once again, its multi-axial nature, requiring much more complex methods such as spectral factorization to be employed.

In QSP and QSVT, the strict constraints that limit performance also simplify the angle finding process. So, though GQSP alleviates the constraints we discussed previously, it also transforms the space in which phase factors can exist from a real interval to a complex unit circle representation. At high degrees, root finding fails in this representation since roots become too closely bunched to properly discern, making this a bottleneck for GQSP. There are many viable tools that can be used instead, such as the non-linear Fourier transform, that do allow us to access higher degree polynomials. This remains an active research topic, so who knows what improved methods are on the horizon!

Despite the potentially higher upfront cost of angle finding for GQSP, our investment is paid back in terms of the flexibility we gain when we remove the polynomial constraints discussed previously. The complexity of the angle finding methods required, however, emphasizes the fact that more classical computational power is required to implement GQSP than QSP and QSVT. So, in addition to the requirements of the problem, we must also remain aware of the limitations of our system when deciding which methods are optimal for our purposes.

The Big Decision

We now understand the ways in which each of these methods is constrained, the reason some are more constrained than others, and how exactly the angle finding bottleneck limits each technique individually. The question remains, though, as to definitively which technique should be used and when. The following table details which methods are recommended in the given scenarios. If your situation does not fit into any of these categories, it is likely that none of these methods will help!

Flowchart Diagram

These distinctions are not without caveats, though, that rely on the capabilities of your particular computational system. Whether or not you can carry out LCU, execute QSVT/QSP for a high-degree function, or satisfy the resource conditions for an arbitrary number of operations is completely variable. When one has the right tool in mind, though, answering the question of feasibility becomes much more clear cut.

Conclusion

Jargon can be intimidating. Especially to those starting out or making a career transition, trying to catch up to the state-of-the-art in a fast-moving industry is hard enough without having to dig for definitions and delimitations. Hopefully, and especially if these descriptions apply to you, this brief battle of QSP vs. QSVT vs. GQSP has shone some light on the use cases of each. If you’re looking for a chance to really get into the technicalities of these methods, take another scroll through this exploration and take advantage of the many resources PennyLane has to offer. Good luck!

About the author

Emily Nobes
Emily Nobes

Emily Nobes

Emily is a 2026 Xanadu summer resident and a Master of Science in Physics student at McGill University. She works on integrated photonic hardware and has historically dabbled in quantum encryption.

Last modified: August 18, 2026

Related Blog Posts

Never miss a milestone

Get the latest quantum updates delivered to your inbox.

Join the list
PennyLane

PennyLane is an open-source quantum software platform for quantum computing, quantum machine learning, and quantum chemistry. Create meaningful quantum algorithms, from inspiration to implementation.

Created with ❤️ by Xanadu.

Research

  • Research

  • Performance

  • Hardware and simulators

  • Demos library

  • Compilation hub

  • Quantum datasets

Education

  • Teach

  • Learn

  • Codebook

  • Coding challenges

  • Videos

  • Glossary

Software

  • Install

  • Features

  • PennyLane documentation

  • Catalyst documentation

  • Development guide

  • How-to guides

  • API

  • GitHub


Xanadu

Š Copyright 2026 | Xanadu | All rights reserved

TensorFlow, the TensorFlow logo and any related marks are trademarks of Google Inc.

Privacy policyTerms of serviceCookies policyCode of conduct