Merge branch 'master' of https://github.com/Happy-Diode/GraphTensorNetworks.jl

Author: GiggleLiu

docs/make.jl

@@ -44,6 +44,7 @@ makedocs(;
         ],
         "Topics" => [
             "Save and load solutions" => "tutorials/saveload.md"
+            "Sum product tree representation" => "sumproduct.md"
             "Weighted problems" => "tutorials/weighted.md"
             "Open degree of freedoms" => "tutorials/open.md"
         ],

docs/src/index.md

@@ -8,8 +8,8 @@ This package implements generic tensor networks to compute *solution space prope
 The *solution space properties* include
 * The maximum/minimum solution sizes,
 * The number of solutions at certain sizes,
-* The enumeration of solutions at certian sizes.
-* The direct sampling of solutions at certian sizes.
+* The enumeration of solutions at certain sizes.
+* The direct sampling of solutions at certain sizes.
 
 The solvable problems include [Independent set problem](@ref), [Maximal independent set problem](@ref), [Cutting problem (Spin-glass problem)](@ref), [Vertex matching problem](@ref), [Binary paint shop problem](@ref), [Coloring problem](@ref), [Dominating set problem](@ref), [Set packing problem](@ref) and [Set covering problem](@ref).
 

docs/src/performancetips.md

@@ -13,33 +13,32 @@ julia> problem = IndependentSet(graph; optimizer=TreeSA(
     sc_target=20, sc_weight=1.0, rw_weight=3.0, ntrials=10, βs=0.01:0.1:15.0, niters=20), simplifier=MergeGreedy());
 ```
 
-The [`IndependentSet`](@ref) constructor maps a independent set problem to a tensor network with optimized contraction order.
+The [`IndependentSet`](@ref) constructor maps an independent set problem to a tensor network with optimized contraction order.
 The key word argument `optimizer` specifies the contraction order optimizer of the tensor network.
-Here, we choose the local search based [`TreeSA`](@ref) algorithm,
-which is one of the state of the art contraction order optimizer detailed in [arXiv: 2108.05665](https://arxiv.org/abs/2108.05665).
-One can type `?TreeSA` in a Julia REPL for more information about how to configure the hyper-parameters of the `TreeSA` method.
-Alternative tensor network contraction orders optimizers include
+Here, we choose the local search based [`TreeSA`](@ref) algorithm, which often finds the smallest time/space complexity and supports slicing.
+One can type `?TreeSA` in a Julia REPL for more information about how to configure the hyper-parameters of the [`TreeSA`](@ref) method, 
+while the detailed algorithm explanation is in [arXiv: 2108.05665](https://arxiv.org/abs/2108.05665).
+Alternative tensor network contraction order optimizers include
 * [`GreedyMethod`](@ref) (default, fastest in searching speed but worst in contraction complexity)
-* [`TreeSA`](@ref) (often best in contraction complexity, supports slicing)
 * [`KaHyParBipartite`](@ref)
 * [`SABipartite`](@ref)
 
-The keyword argument `simplifier` is for preprocessing sub-routine to improve the searching speed of the contraction order finding.
+The keyword argument `simplifier` specifies the preprocessor to improve the searching speed of the contraction order finding.
 For example, the `MergeGreedy()` here "contracts" tensors greedily whenever the contraction result has a smaller space complexity.
 It can remove all vertex tensors (vectors) before entering the contraction order optimization algorithm.
 
-The returned instance `problem` contains a field `code` that specifies the tensor network contraction order. For an independent set problem, its contraction time space complexity is ``2^{{\rm tw}(G)}``, where ``{\rm tw(G)}`` is the [tree-width](https://en.wikipedia.org/wiki/Treewidth) of ``G``.
-One can check the time, space and read-write complexity with the following function.
+The returned object `problem` contains a field `code` that specifies the tensor network with optimized contraction order.
+For an independent set problem, the optimal contraction time/space complexity is ``\sim 2^{{\rm tw}(G)}``, where ``{\rm tw(G)}`` is the [tree-width](https://en.wikipedia.org/wiki/Treewidth) of ``G``.
+One can check the time, space and read-write complexity with the [`timespacereadwrite_complexity`](@ref) function.
 
 ```julia
 julia> timespacereadwrite_complexity(problem)
 (21.90683335864693, 17.0, 20.03588509836998)
 ```
 
-The return values are `log2` of the the number of iterations, the number elements in the largest tensor during contraction and the number of read-write operations to tensor elements.
-In this example, the number of `+` and `*` operations are both ``\sim 2^{21.9}``
-and the number of read-write operations are ``\sim 2^{20}``.
-The largest tensor size is ``2^{17}``, one can check the element size by typing
+The return values are `log2` values of the number of multiplications, the number elements in the largest tensor during contraction and the number of read-write operations to tensor elements.
+In this example, the number `*` operations is ``\sim 2^{21.9}``, the number of read-write operations are ``\sim 2^{20}``, and the largest tensor size is ``2^{17}``.
+One can check the element size by typing
 ```julia
 julia> sizeof(TropicalF64)
 8
@@ -55,20 +54,19 @@ julia> sizeof(TruncatedPoly{5,Float64,Float64})
 ```
 
 One can use [`estimate_memory`](@ref) to get a good estimation of peak memory in bytes.
+For example, to compute the graph polynomial, the peak memory can be estimated as follows.
 ```julia
 julia> estimate_memory(problem, GraphPolynomial(; method=:finitefield))
 297616
 
 julia> estimate_memory(problem, GraphPolynomial(; method=:polynomial))
 71427840
 ```
-It means one only needs 298 KB memory to find the graph polynomial with the finite field approach,
-but needs 71 MB memory to find the graph polynomial using the [`Polynomial`](https://juliamath.github.io/Polynomials.jl/stable/polynomials/polynomial/#Polynomial-2) type.
+The finite field approach only requires 298 KB memory, while using the [`Polynomial`](https://juliamath.github.io/Polynomials.jl/stable/polynomials/polynomial/#Polynomial-2) number type requires 71 MB memory.
 
 !!! note
-    * The actual run time memory can be several times larger than the size of the maximum tensor.
-    There is no constant bound for the factor, an empirical value for it is 3x.
-    * For mutable types like [`Polynomial`](https://juliamath.github.io/Polynomials.jl/stable/polynomials/polynomial/#Polynomial-2) and [`ConfigEnumerator`](@ref), the `sizeof` function does not measure the actual element size.
+    * The actual run time memory can be several times larger than the size of the maximum tensor, so the [`estimate_memory`](@ref) is more accurate in estimating the peak memory.
+    * For mutable element types like [`ConfigEnumerator`](@ref), none of memory estimation functions measure the actual memory usage correctly.
 
 ## Slicing
 
@@ -98,7 +96,7 @@ In this application, the slicing achieves the largest possible space complexity
 i.e. the peak memory usage is reduced by a factor ``32``, while the (theoretical) computing time is increased by at a factor ``< 2``.
 
 ## GEMM for Tropical numbers
-You can speed up the Tropical number matrix multiplication when computing `SizeMax()` by using the Tropical GEMM routines implemented in package [`TropicalGEMM.jl`](https://github.com/TensorBFS/TropicalGEMM.jl/).
+One can speed up the Tropical number matrix multiplication when computing the solution space property [`SizeMax`](@ref)`()` by using the Tropical GEMM routines implemented in package [`TropicalGEMM`](https://github.com/TensorBFS/TropicalGEMM.jl/).
 
 ```julia
 julia> using BenchmarkTools
@@ -116,65 +114,19 @@ julia> @btime solve(problem, SizeMax())
 53.0ₜ
 ```
 
-The `TropicalGEMM` pirates the `LinearAlgebra.mul!` interface, hence it takes effect upon using.
-The GEMM routine can speed up the computation on CPU for one order, with multi-threading, it can be even faster.
-Benchmark shows the performance of `TropicalGEMM` is close to the theoretical optimal value.
-
-## Sum product representation for configurations
-[`SumProductTree`](@ref) (an alias of [`SumProductTree`](@ref) with [`StaticElementVector`](@ref) as its data type) can save a lot memory for you to store exponential number of configurations in polynomial space.
-It is a sum-product expression tree to store [`ConfigEnumerator`](@ref) in a lazy style, configurations can be extracted by depth first searching the tree with the `Base.collect` method. Although it is space efficient, it is in general not easy to extract information from it.
-This tree structure supports directed sampling so that one can get some statistic properties from it with an intermediate effort.
-
-For example, if we want to check some property of an intermediate scale graph, one can type
-```julia
-julia> graph = random_regular_graph(70, 3)
-
-julia> problem = IndependentSet(graph; optimizer=TreeSA());
-
-julia> tree = solve(problem, ConfigsAll(; tree_storage=true))[];
-16633909006371
-```
-If one wants to store these configurations, he will need a hard disk of size 256 TB!
-However, this sum-product binary tree structure supports efficient and unbiased direct sampling.
-
-```julia
-samples = generate_samples(tree, 1000);
-```
-
-With these samples, one can already compute useful properties like distribution of hamming distance (see [`hamming_distribution`](@ref)).
-
-```julia
-julia> using UnicodePlots
-
-julia> lineplot(hamming_distribution(samples, samples))
-          ┌────────────────────────────────────────┐ 
-   100000 │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠹⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡎⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⡇⠀⢣⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠸⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠃⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠁⠀⠀⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⡼⠀⠀⠀⠀⠀⠀⠈⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-          │⠀⠀⠀⠀⠀⠀⠀⠀⢠⠇⠀⠀⠀⠀⠀⠀⠀⢳⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
-        0 │⢀⣀⣀⣀⣀⣀⣀⣀⠎⠀⠀⠀⠀⠀⠀⠀⠀⠀⠓⢄⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⠀⠀⠀⠀│ 
-          └────────────────────────────────────────┘ 
-          ⠀0⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀80⠀ 
-```
+The `TropicalGEMM` package pirates the `LinearAlgebra.mul!` interface, hence it takes effect upon using.
+The above example shows more than 10x speed up on a single thread CPU, which can be even faster if [the Julia multi-threading](https://docs.julialang.org/en/v1/manual/multi-threading/) if turned on.
+The benchmark in the `TropicalGEMM` repo shows this performance is close to the theoretical optimal value.
 
 ## Multiprocessing
-Submodule `GenericTensorNetworks.SimpleMutiprocessing` provides a function [`GenericTensorNetworks.SimpleMultiprocessing.multiprocess_run`](@ref) function for simple multi-processing jobs.
+Submodule `GenericTensorNetworks.SimpleMutiprocessing` provides one function [`GenericTensorNetworks.SimpleMultiprocessing.multiprocess_run`](@ref) function for simple multi-processing jobs.
+It is not directly related to `GenericTensorNetworks`, but is very convenient to have one.
 Suppose we want to find the independence polynomial for multiple graphs with 4 processes.
 We can create a file, e.g. named `run.jl` with the following content
 
 ```julia
 using Distributed, GenericTensorNetworks.SimpleMultiprocessing
-using Random, GenericTensorNetworks  # to avoid multi-precompiling
+using Random, GenericTensorNetworks  # to avoid multi-precompilation
 @everywhere using Random, GenericTensorNetworks
 
 results = multiprocess_run(collect(1:10)) do seed
@@ -207,7 +159,7 @@ $ julia -p4 run.jl
 You will see a vector of polynomials printed out.
 
 ## Make use of GPUs
-To upload the computing to GPU, you just add need to use CUDA, and offer a new key word argument.
+To upload the computation to GPU, you just add `using CUDA` before calling the `solve` function, and set the keyword argument `usecuda` to `true`.
 ```julia
 julia> using CUDA
 [ Info: OMEinsum loaded the CUDA module successfully
@@ -217,9 +169,9 @@ julia> solve(problem, SizeMax(), usecuda=true)
 53.0ₜ
 ```
 
-CUDA backended properties are
+Solution space properties computable on GPU includes
 * [`SizeMax`](@ref) and [`SizeMin`](@ref)
 * [`CountingAll`](@ref)
 * [`CountingMax`](@ref) and [`CountingMin`](@ref)
 * [`GraphPolynomial`](@ref)
-* [`SingleConfigMax`](@ref) and [`SingleConfigMin`](@ref)
+* [`SingleConfigMax`](@ref) and [`SingleConfigMin`](@ref)

docs/src/sumproduct.md

@@ -0,0 +1,47 @@
+# Sum product representation for configurations
+[`SumProductTree`](@ref) can use polynomial memory to store exponential number of configurations.
+It is a sum-product expression tree to store [`ConfigEnumerator`](@ref) in a lazy style, where configurations can be extracted by depth first searching the tree with the `Base.collect` method.
+Although it is space efficient, it is in general not easy to extract information from it due to the exponential large configuration space.
+Directed sampling is one of its most important operations, with which one can get some statistic properties from it with an intermediate effort. For example, if we want to check some property of an intermediate scale graph, one can type
+```julia
+julia> graph = random_regular_graph(70, 3)
+
+julia> problem = IndependentSet(graph; optimizer=TreeSA());
+
+julia> tree = solve(problem, ConfigsAll(; tree_storage=true))[];
+16633909006371
+```
+If one wants to store these configurations, he will need a hard disk of size 256 TB!
+However, this sum-product binary tree structure supports efficient and unbiased direct sampling.
+
+```julia
+samples = generate_samples(tree, 1000);
+```
+
+With these samples, one can already compute useful properties like Hamming distance (see [`hamming_distribution`](@ref)) distribution.
+
+```julia
+julia> using UnicodePlots
+
+julia> lineplot(hamming_distribution(samples, samples))
+          ┌────────────────────────────────────────┐ 
+   100000 │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠹⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡎⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⡇⠀⢣⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠸⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠃⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⠁⠀⠀⠀⠀⠀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⠀⡼⠀⠀⠀⠀⠀⠀⠈⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+          │⠀⠀⠀⠀⠀⠀⠀⠀⢠⠇⠀⠀⠀⠀⠀⠀⠀⢳⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
+        0 │⢀⣀⣀⣀⣀⣀⣀⣀⠎⠀⠀⠀⠀⠀⠀⠀⠀⠀⠓⢄⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⠀⠀⠀⠀│ 
+          └────────────────────────────────────────┘ 
+          ⠀0⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀80⠀ 
+```
+
+Here, the ``x``-axis is the Hamming distance and the ``y``-axis is the counting of pair-wise Hamming distances.

examples/Coloring.jl

@@ -25,7 +25,7 @@ problem = Coloring{3}(graph);
 
 # ### Theory (can skip)
 # Type [`Coloring`](@ref) can be used for constructing the tensor network with optimized contraction order for a coloring problem.
-# Let us use 3-colouring problem defined on vertices as an example.
+# Let us use 3-coloring problem defined on vertices as an example.
 # For a vertex ``v``, we define the degree of freedoms ``c_v\in\{1,2,3\}`` and a vertex tensor labelled by it as
 # ```math
 # W(v) = \left(\begin{matrix}
@@ -42,7 +42,7 @@ problem = Coloring{3}(graph);
 #     x & x & 1
 # \end{matrix}\right).
 # ```
-# The number of possible colouring can be obtained by contracting this tensor network by setting vertex tensor elements ``r_v, g_v`` and ``b_v`` to 1.
+# The number of possible coloring can be obtained by contracting this tensor network by setting vertex tensor elements ``r_v, g_v`` and ``b_v`` to 1.
 
 # ## Solving properties
 # ##### counting all possible coloring

examples/DominatingSet.jl

@@ -28,7 +28,7 @@ problem = DominatingSet(graph; optimizer=TreeSA());
 # ### Theory (can skip)
 # Let ``G=(V,E)`` be the target graph that we want to solve.
 # The tensor network representation map a vertex ``v\in V`` to a boolean degree of freedom ``s_v\in\{0, 1\}``.
-# We defined the restriction on a vertex and its neighbouring vertices ``N(v)``:
+# We defined the restriction on a vertex and its neighboring vertices ``N(v)``:
 # ```math
 # T(x_v)_{s_1,s_2,\ldots,s_{|N(v)|},s_v} = \begin{cases}
 #     0 & s_1=s_2=\ldots=s_{|N(v)|}=s_v=0,\\
@@ -37,7 +37,7 @@ problem = DominatingSet(graph; optimizer=TreeSA());
 # \end{cases}
 # ```
 # where ``w_v`` is the weight of vertex ``v``.
-# This tensor means if both ``v`` and its neighbouring vertices are not in ``D``, i.e., ``s_1=s_2=\ldots=s_{|N(v)|}=s_v=0``,
+# This tensor means if both ``v`` and its neighboring vertices are not in ``D``, i.e., ``s_1=s_2=\ldots=s_{|N(v)|}=s_v=0``,
 # this configuration is forbidden because ``v`` is not adjacent to any member in the set.
 # otherwise, if ``v`` is in ``D``, it has a contribution ``x_v^{w_v}`` to the final result.
 # One can check the contraction time space complexity of a [`DominatingSet`](@ref) instance by typing: