Add codespell, consistent US english style & correct typos

.github/workflows/ruff_checks.yml → .github/workflows/lint.yml

@@ -1,4 +1,4 @@
-name: Code style checks
+name: lint
 
 on:
   pull_request:
@@ -18,7 +18,7 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-  ruff:
+  lint:
     runs-on: ubuntu-latest
     strategy:
       matrix:
@@ -37,7 +37,11 @@ jobs:
         uses: astral-sh/ruff-action@v3
         with:
           args: format --check
-      # - name: Ruff linter
-      #   uses: astral-sh/ruff-action@v3
-      #   with:
-      #     args: check  # wait for fix from Niko's student
+      - name: Codespell
+        run: |
+          codespell || {
+            echo "::warning::The Qrisp project uses American English. Found spelling issues (see above)."
+            echo "::warning::Run 'codespell' locally to see the full list, or 'codespell -w' to auto-fix."
+            echo "::warning::To suppress: add '# codespell:ignore' to the line, or add the keyword to 'ignore-words-list' in pyproject.toml."
+            exit 1
+          }

documentation/source/_static/css/custom09.css

@@ -22,7 +22,7 @@ html[data-theme="dark"] {
   --pst-color-plot-background: rgb(218, 219, 220);
 }
 
-/* PyDataSphinx link underlining overide */
+/* PyDataSphinx link underlining override */
 .bd-header .navbar-nav li a.nav-link:hover {
   text-decoration: none !important;
   color: var(--pst-color-primary);

documentation/source/_static/js/frontpage-interactions.js

@@ -145,7 +145,7 @@
     if (pos === 'static' || pos === '') qrispPre.style.position = 'relative';
     qrispPre.style.overflow = 'hidden';
 
-    /* Get the background colour so the overlay blends seamlessly */
+    /* Get the background color so the overlay blends seamlessly */
     var bg = style.backgroundColor;
     if (!bg || bg === 'transparent' || bg === 'rgba(0, 0, 0, 0)') bg = '#f8f8f8';
 

documentation/source/general/changelog/changelog-dev.rst

@@ -45,6 +45,10 @@ API Changes
 Development
 -----------
 
+* Added ``codespell`` configuration for automated typo checking and fixed typos
+  across documentation, source code, and tests
+  (`PR #716 <https://github.com/eclipse-qrisp/Qrisp/pull/716>`_).
+
 * Added Dependabot configuration for automated dependency updates
   (grouped by type, with labels applied automatically).
 

documentation/source/general/changelog/index.rst

@@ -9,7 +9,6 @@ Version history
 .. toctree::
    :maxdepth: 2
 
-   0.10
    0.9
    0.8
    0.7

documentation/source/general/papers/index.rst

@@ -63,7 +63,7 @@ Research from within the Qrisp community
 
             The rise of quantum computing/technology potentially introduces significant security challenges to cloud computing, 
             necessitating quantum-resistant encryption strategies as well as protection schemes and methods for cloud infrastructures offering quantum computing time and services (i.e. quantum clouds). 
-            This research explores various options for securing quantum clouds and ensuring privacy, especially focussing on the integration of homomorphic encryption (HE) into Eclipse Qrisp, 
+            This research explores various options for securing quantum clouds and ensuring privacy, especially focusing on the integration of homomorphic encryption (HE) into Eclipse Qrisp, 
             a high-level quantum computing framework, to enhance the security of quantum cloud platforms. The study addresses the technical feasibility of integrating HE with Qrisp, 
             evaluates performance trade-offs, and assesses the potential impact on future quantum cloud architectures. 
             The successful implementation and Qrisp integration of three post-quantum cryptographic (PQC) algorithms demonstrates the feasibility of integrating HE with quantum computing frameworks. 

documentation/source/general/tutorial/BE_tutorial/BE_vol1.ipynb

@@ -350,7 +350,7 @@
     "\n",
     "The negative sign matches the chosen finite-difference convention.\n",
     "\n",
-    "This decomposition fits naturally into the LCU framework, because $\\mathbb{I}$, $V$, and $V^\\dagger$ are themselves unitaries, afterall:$$\\Delta=\\sum_{i=0}^2\\alpha_i U_i\\propto 2\\mathbb{I}-V-V^\\dagger$$\n",
+    "This decomposition fits naturally into the LCU framework, because $\\mathbb{I}$, $V$, and $V^\\dagger$ are themselves unitaries, after all:$$\\Delta=\\sum_{i=0}^2\\alpha_i U_i\\propto 2\\mathbb{I}-V-V^\\dagger$$\n",
     "\n",
     "This can be easily implemented in Qrisp with the [built-in arithmetic](../../../reference/Quantum%20Types/QuantumFloat.rst) it allows:"
    ]
@@ -403,7 +403,7 @@
    "id": "42f78d52",
    "metadata": {},
    "source": [
-    "And thats it... that's all the ingredients we need to define a custom block encoding with [.from_lcu](../../../reference/Block%20Encodings/methods/from_lcu.rst). We just provide the coefficients and the unitaries, and the BlockEncoding class does all the management of the coefficients, ancillary qubits, and whatever else under the sun. In future releases we also want it to be able do perform one's taxes.\n",
+    "And that's it... that's all the ingredients we need to define a custom block encoding with [.from_lcu](../../../reference/Block%20Encodings/methods/from_lcu.rst). We just provide the coefficients and the unitaries, and the BlockEncoding class does all the management of the coefficients, ancillary qubits, and whatever else under the sun. In future releases we also want it to be able do perform one's taxes.\n",
     "\n",
     "All jokes aside, let's block encode this Laplacian and check the resources if it's actually more efficient (it is) before explaining why it's more efficient."
    ]
@@ -592,7 +592,7 @@
    "id": "c59936ef",
    "metadata": {},
    "source": [
-    "If we, again, compare the two results, as well as the variance, we see that the quantum results fluctuate by quite a lot. It is becasue of the probabilistic nature of quantum computation - if we would increase the number of shots, the variance would decrease, and the results won't fluctuate that much.\n",
+    "If we, again, compare the two results, as well as the variance, we see that the quantum results fluctuate by quite a lot. It is because of the probabilistic nature of quantum computation - if we would increase the number of shots, the variance would decrease, and the results won't fluctuate that much.\n",
     "\n",
     "This is the NISQ way, post-selection based to solve this. We designed Qrisp as being forward thinking with a lot of the infrastructure required for the Fault Tolerance era already introduced, like real-time measurements and repeat until success procedures. Let's show how to use the latter with our BlockEncodings, and see how the variance of the results looks like then.\n",
     "\n",
@@ -669,7 +669,7 @@
    "id": "a5012b2a",
    "metadata": {},
    "source": [
-    "A few things to note here. We pass the operand (the state we have prepared and want to apply the operator to) as a function, as oppossed as a [QuantumVariable](../../../reference/Core/QuantumVariable.rst). The second difference is the way we obtain the BlockEncoding and apply the [.apply_rus](../../../reference/Block%20Encodings/methods/apply_rus.rst), which is within a main function. This is because we use the [Jasp](../../../reference/Jasp/index.rst) compilation pipeline, which allows us to avoid the pythonic compilation bottleneck. You can learn more about it in the Jasp tutorial.\n",
+    "A few things to note here. We pass the operand (the state we have prepared and want to apply the operator to) as a function, as opposed as a [QuantumVariable](../../../reference/Core/QuantumVariable.rst). The second difference is the way we obtain the BlockEncoding and apply the [.apply_rus](../../../reference/Block%20Encodings/methods/apply_rus.rst), which is within a main function. This is because we use the [Jasp](../../../reference/Jasp/index.rst) compilation pipeline, which allows us to avoid the pythonic compilation bottleneck. You can learn more about it in the Jasp tutorial.\n",
     "\n",
     "Next, we invoke the [@terminal_sampling](../../../reference/Jasp/Simulation%20Tools/Terminal%20Sampling.rst) decorator. Simply put, this decorator tells the compiler to simulate the quantum program using our fast state vector simulator and sample the final measurement distribution. Instead of manually writing a classical loop to execute the program repeatedly and gather measurement statistics, [@terminal_sampling](../../../reference/Jasp/Simulation%20Tools/Terminal%20Sampling.rst) automatically handles the heavy lifting of sampling this probability.\n",
     "In the end, we obtain a result that is consistent when repeating the simulation. \n",

documentation/source/general/tutorial/BE_tutorial/BE_vol2.ipynb

@@ -552,7 +552,7 @@
     "\n",
     "QSVT applies a polynomial $P$ to the singular values of a matrix $A$ without needing to perform a full Singular Value Decomposition (SVD). \n",
     "\n",
-    "Disclaimer, a bit more maths before showing examples of how to perform this simply and intuitevely as methods of the class we've been covering.\n",
+    "Disclaimer, a bit more math before showing examples of how to perform this simply and intuitevely as methods of the class we've been covering.\n",
     "\n",
     "Consider a matrix $A \\in \\mathbb{C}^{m \\times n}$ with $\\|A\\| \\leq 1$ with SVD of $A = \\sum_{i} \\sigma_i \\ket{w_i} \\bra{v_i}$. If we have a $(\\alpha, m, \\epsilon)$-block encoding $U$, our goal is to construct a new unitary $U_\\Phi$ that implements:\n",
     "$$P(A) = \\sum_{i} P(\\sigma_i) \\ket{w_i} \\bra{v_i}.$$\n",
@@ -563,7 +563,7 @@
     "\n",
     "![QSVT](BE_QSVT.png)\n",
     "\n",
-    "You might be saying to yourself: \"The picture is confusing to me. In the formula for $U_\\Phi$ only $U$ and $\\Pi$ appear, but at no point $\\ket{G}$?!\". What a great question you brewed there! The answer might suprise you, but it's mostly the notation used in literature. In the algorithm schematics above we have explicitly shown the $\\ket{G}$ and $\\bra{G}$ parts sandwiching $U$. In literature, it is often assumed, that these unitaries are collectively labeled as $U$: $U\\rightarrow (\\bra{G}\\otimes \\mathbb{I})U(\\ket{G}\\otimes \\mathbb{I})$.\n",
+    "You might be saying to yourself: \"The picture is confusing to me. In the formula for $U_\\Phi$ only $U$ and $\\Pi$ appear, but at no point $\\ket{G}$?!\". What a great question you brewed there! The answer might surprise you, but it's mostly the notation used in literature. In the algorithm schematics above we have explicitly shown the $\\ket{G}$ and $\\bra{G}$ parts sandwiching $U$. In literature, it is often assumed, that these unitaries are collectively labeled as $U$: $U\\rightarrow (\\bra{G}\\otimes \\mathbb{I})U(\\ket{G}\\otimes \\mathbb{I})$.\n",
     "\n",
     "As promised above, you don't even need to care about these angles with our crispy clean implementation. Generalizing QSP is the final piece of this mosaic.\n",
     "\n",
@@ -580,7 +580,7 @@
     "\n",
     "Why does this generalization matter so much? It allows for mixed parity polynomial, resulting in you being to implement functions like $e^{-iAt}$ directly without splitting them into sine (odd) and cosine (even) components.\n",
     "\n",
-    "Apart from that, finding precise phase factors for standard QSP/QSVT relied on specialized libaries like [QSPPACK](https://qsppack.gitbook.io/qsppack) or [pyqsp](https://github.com/ichuang/pyqsp) to handle the underlying numerical optimization. In the Generalized (GQSP) framework, phases can be computed efficiently (see [Laneve](https://arxiv.org/abs/2503.03026), [Ni et al.](https://arxiv.org/pdf/2505.12615)) in time $\\mathcal O(d\\log(d))$, making it more accessible. (Of course this is already integrated in Qrisp, such that you don't have to care about these phases.)\n",
+    "Apart from that, finding precise phase factors for standard QSP/QSVT relied on specialized libraries like [QSPPACK](https://qsppack.gitbook.io/qsppack) or [pyqsp](https://github.com/ichuang/pyqsp) to handle the underlying numerical optimization. In the Generalized (GQSP) framework, phases can be computed efficiently (see [Laneve](https://arxiv.org/abs/2503.03026), [Ni et al.](https://arxiv.org/pdf/2505.12615)) in time $\\mathcal O(d\\log(d))$, making it more accessible. (Of course this is already integrated in Qrisp, such that you don't have to care about these phases.)\n",
     "\n",
     "The structure of GQSP is shown in the following schematics:\n",
     "\n",
@@ -719,7 +719,7 @@
    "id": "95af2576",
    "metadata": {},
    "source": [
-    "Let's compare the resources of this approach to the one we mentioned above under the abbriviation CKS:"
+    "Let's compare the resources of this approach to the one we mentioned above under the abbreviation CKS:"
    ]
   },
   {
@@ -973,7 +973,7 @@
    "source": [
     "We see that we need only 17 Chebyshevs for this, which is peanuts compared to 4238761233361477633 terms we'd need to approximate the inverse of $L_\\text{ill}$. This is something that we share with our classical colleagues, where the problem of ill-conditioning is still present. There is definititely tricks that we can learn (or rather copy their homework) in the form of [preconditioning](https://en.wikipedia.org/wiki/Preconditioner) our ill-conditioned matrices.\n",
     "\n",
-    "Concluding this side quest (deciding  on how well conditioned this side quest actually was is left as an exercise for the reader), let's actually comment on the results of comparing the resources: CKS ain't too shabby afterall! This is why, fellow readers, you should always do your due diligence and perform analysis of the resources. \"Big O\" notation can be misleading because it ommits the scaling factors. Well, in this case the results were actually expected because the underlying structures of both algorithms are extremely similar (apart from the qubits required to performs controls on). But still, estimate your quantum resources!"
+    "Concluding this side quest (deciding  on how well conditioned this side quest actually was is left as an exercise for the reader), let's actually comment on the results of comparing the resources: CKS ain't too shabby after all! This is why, fellow readers, you should always do your due diligence and perform analysis of the resources. \"Big O\" notation can be misleading because it omits the scaling factors. Well, in this case the results were actually expected because the underlying structures of both algorithms are extremely similar (apart from the qubits required to performs controls on). But still, estimate your quantum resources!"
    ]
   },
   {
@@ -1030,7 +1030,7 @@
    "id": "fc4dcca6",
    "metadata": {},
    "source": [
-    "The result dictionary shows the measurement probabilites for evolved state\n",
+    "The result dictionary shows the measurement probabilities for evolved state\n",
     "    \n",
     "$$ \\ket{\\psi(t)} = \\dfrac{e^{itH}\\ket{0}}{\\|e^{itH}\\ket{0}\\|}. $$"
    ]
@@ -1044,7 +1044,7 @@
     "\n",
     "As hopefully you're now convinced, having block encodings as programming abstractions lowers the barrier to entry for classical developers to dive into the field of state-of-the-art quantum computing algorithms, while at the same time allowing researchers to focus on the algorithm (the function to be applied) rather than the software implementations!\n",
     "\n",
-    "A quick collection of take-home messages after this throrough (and math heavy) tutorial. We have transitioned from basic matrix representations to complex functional analysis on a quantum computer:\n",
+    "A quick collection of take-home messages after this thorough (and math heavy) tutorial. We have transitioned from basic matrix representations to complex functional analysis on a quantum computer:\n",
     "\n",
     "- Qubitization is the engine that enables walking through 2D subspaces.\n",
     "\n",

documentation/source/general/tutorial/CD.ipynb

@@ -26,7 +26,7 @@
     "The adiabatic condition roughly tells us that in order to avoid transitions to exited states we must drive the system slow compared to the size of the energetic gaps. Unfortunately, we cannot push this evolution time too strongly as this leads to quantum incoherences and disruption through noise.\n",
     "Therefore we want to mitigate the diabatic transitions so that we can drive the system adiabatically while keeping the evolution time short.\n",
     "\n",
-    "To understand how diabatic transitions can be mitigated, we need to introduce the **adiabatic gauge potential (AGP)** $A_{\\lambda}$. This is a hermitian operator whose diagonal elements desribe the *adiabatic-* (phase accumulation) and its off-diagonal elements describe the *non-adiabatic* (transition-inducing) dynamics of the driven system. It is related to the state evolution in the instantaneous eigenbasis (denoted by $\\sim$):\n",
+    "To understand how diabatic transitions can be mitigated, we need to introduce the **adiabatic gauge potential (AGP)** $A_{\\lambda}$. This is a hermitian operator whose diagonal elements describe the *adiabatic-* (phase accumulation) and its off-diagonal elements describe the *non-adiabatic* (transition-inducing) dynamics of the driven system. It is related to the state evolution in the instantaneous eigenbasis (denoted by $\\sim$):\n",
     "\n",
     "$$ i \\hbar \\frac{d\\ket{\\tilde{\\Psi}}}{dt} = \\left( \\tilde{H} - \\frac{\\partial \\lambda}{\\partial t} A_{\\lambda} \\right) \\ket{\\tilde{\\Psi}} $$\n",
     "\n",
@@ -53,7 +53,7 @@
     "\n",
     "$$ S(A_{\\lambda}) = \\mathrm{Tr} \\{ G_{\\lambda}^2(A_{\\lambda}) \\} $$\n",
     "\n",
-    "Where $G_{\\lambda}$ is an operator that is the negation of the generalised force operator.\n",
+    "Where $G_{\\lambda}$ is an operator that is the negation of the generalized force operator.\n",
     "\n",
     "$$ G_{\\lambda}(A_{\\lambda}) = \\partial_{\\lambda} H + \\frac{i}{\\hbar} \\left[ A_{\\lambda}, H \\right] $$\n",
     "\n",
@@ -82,7 +82,7 @@
    "source": [
     "# QUBO problems as CD instances\n",
     "\n",
-    "A QUBO probelem is a combinatorical optimization problem that can be formulated as\n",
+    "A QUBO probelem is a combinatorial optimization problem that can be formulated as\n",
     "\n",
     "$$ \\mathrm{min} \\ y = x^T Q x, $$\n",
     "\n",
@@ -365,7 +365,7 @@
    "source": [
     "### Run a LCD problem\n",
     "\n",
-    "We can also use the LCD algorithm without the optimized control pulse. This can be done by ommiting the control hamiltonian and choosing ``method = \"LCD\"``. Here is how you run the above example with LCD:"
+    "We can also use the LCD algorithm without the optimized control pulse. This can be done by omitting the control hamiltonian and choosing ``method = \"LCD\"``. Here is how you run the above example with LCD:"
    ]
   },
   {
@@ -424,7 +424,7 @@
     "$$ f_{CRAB}(\\lambda, \\beta) \\mathcal{O}_{opt} = \\sum_{k=1}^{N_{opt}} \\beta_k \\sin(\\pi (k + r_k) g(\\lambda)) \\sum_i \\sigma_z^{i}. $$\n",
     "\n",
     "This leads to a small variation of each basis vector and can reduce the risk to get stuck in a local optimization minimum [[2]](https://doi.org/10.1103/PRXQuantum.4.010312).\n",
-    "To use the CRAB extention of COLD, simply hand over ``\"CRAB\": True`` in the ``run_args`` dictionary."
+    "To use the CRAB extension of COLD, simply hand over ``\"CRAB\": True`` in the ``run_args`` dictionary."
    ]
   },
   {
@@ -445,7 +445,7 @@
     "We have seen how we can use these methods to solve QUBO problems: If we encode the QUBO matrix into a spin-glass hamiltonian and\n",
     "let the groundstate evolve over time, we arrive at the groundstate of our QUBO cost hamiltonian.\n",
     "\n",
-    "The qrisp module ``COLD`` lets you either define the necessarry operators yourself or you can use the ``solve_QUBO`` method\n",
+    "The qrisp module ``COLD`` lets you either define the necessary operators yourself or you can use the ``solve_QUBO`` method\n",
     "to run the algorithm with different pre-defined instances.\n",
     "We encourage you to play around with the different options like the evolution time, size of timesteps, optimization objectives and AGP types! "
    ]