Some more documentation progress #345

Jutho · 2026-01-06T11:25:41Z

This includes a major restructuring (breaking down long pages into separate pages) and a complete rewrite of the Sector documentation. This could become the manual page for TensorKitSectors.jl in time, but for now I would still include it here.

By lack of a good Markdown formatter, I switched to breaking lines at natural places (end of sentence, subsentences, …), like one might do with LaTeX documents. Maybe that strategy can lead to clean git diffs in future (potentially smaller) doc changes, but I am open to other suggestions.

This would very much benefit from some proofreading by e.g. @borisdevos , @leburgel , @lkdvos .

codecov · 2026-01-06T12:12:30Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
see 23 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

github-actions · 2026-01-06T21:51:46Z

After the build completes, the updated documentation will be available here

docs/src/appendix/categories.md

borisdevos · 2026-01-07T07:58:01Z

docs/src/appendix/categories.md

 object ``V``, referred to as `dim(V)` in TensorKit.jl.

 For further information and a more detailed treatment of rigid and pivotal categories, we
 refer to [^turaev] and [^selinger]. We conclude this section by studying the example of


Just an idea, but the way the citations are printed in the docs is precisely how you define it here, so e.g. [turaev] and [selinger]. Do we want to capitalise the names?

Yes that is perhaps a good idea.

docs/src/appendix/categories.md

borisdevos · 2026-01-07T08:10:28Z

docs/src/appendix/categories.md

+Before continuing, let us use some examples to sketch the relevance of the concept of fusion
+categories. As mentioned, the categories ``\mathbf{Vect}_𝕜`` and ``\mathbf{SVect}_𝕜`` have
+``I ≂ 𝕜`` as simple object. For ``\mathbf{Vect}``, this is the only simple object, i.e. any
+other vector space ``V`` over ``𝕜``, can be thought of as a direct sum over


Suggested change

other vector space ``V`` over ``𝕜``, can be thought of as a direct sum over

other vector space ``V`` over ``𝕜`` can be thought of as a direct sum over

docs/src/appendix/categories.md

borisdevos · 2026-01-07T08:26:29Z

docs/src/appendix/categories.md

-    manipulations thereof (in particular orthonormal factorizations such as the singular
-    value decomposition), we find it more convenient to work with the original normalization
-    convention.
+!!! note In the context of fusion categories, one often resorts to the so-called *isotopic*


This note block isn't working. The main text needs to start on a new line with four spaces (https://documenter.juliadocs.org/stable/showcase/#Admonitions)

Actually this might just be an artefact of the preview, since it's fine in the current stable version.

Now I think the note blocks got destroyed by the automatic Markdown formatting that did happen in the final commit because of how my VSCode at the office desktop was set up.

I will have to disable that formatter and revert to manual formatting as I originally intended.

borisdevos · 2026-01-07T08:38:46Z

docs/src/lib/sectors.md


-The following types are used to characterise different properties of the different types
-of sectors:
+The following types are used to characterise different properties of the different types of


Suggested change

The following types are used to characterise different properties of the different types of

The following types are used to characterize different properties of the different types of

Since American English is preferred in the docs

Somehow I cannot commit this suggestion directly so I'll have to change it manually.

borisdevos · 2026-01-07T08:43:25Z

docs/src/lib/sectors.md

-Because we sometimes want to customize the string representation of our sector types,
-we also have the following method:
+Mapping between sectors and linear indices is only used for sectors `I` for which
+`Base.IteratorSize(values(I)) == HasLength()`. In that case, we map an index `i` to a sector


Is this true? I can call e.g. values(SU2Irrep)[3] and it gives SU2Irrep(1)

The original reason for that method is that in the spaces, instead of a Dict{Sector,Int} for the degeneracies we are storing a NTuple{N, Int} and using direct indexing. This requires a finite and compile-time known number of different sectors.
I would have to double check, but I don't think we are really using that function for anything else right now.

But yes, it is true. There is a default getindex(::SectorValues{I}, i) that really just runs the values(I) iterator until it reaches the ith element. The same with findindex(::SectorValues{I}, c::I) that runs the iterator and counts how long it takes before the requested sector c is reached.

borisdevos · 2026-01-07T08:43:58Z

docs/src/lib/spaces.md

-There are also specific methods for `HomSpace` instances, that are used in determining
-the resuling `HomSpace` after applying certain tensor operations.
+There are also specific methods for `HomSpace` instances, that are used in determining the
+resuling `HomSpace` after applying certain tensor operations.


Suggested change

resuling `HomSpace` after applying certain tensor operations.

resulting `HomSpace` after applying certain tensor operations.

This suggestion I can also not commit directly. Very strange.

docs/src/lib/tensors.md

borisdevos · 2026-01-07T08:52:33Z

docs/src/lib/tensors.md

 ```

-For a tensor `t` with `FusionType(sectortype(t)) isa UniqueFusion`, fusion trees are 
+For a tensor `t` with `FusionType(sectortype(t)) isa UniqueFusion`, fusion trees are


Suggested change

For a tensor `t` with `FusionType(sectortype(t)) isa UniqueFusion`, fusion trees are

For a tensor `t` with `FusionStyle(sectortype(t)) isa UniqueFusion`, fusion trees are

borisdevos · 2026-01-07T08:52:58Z

docs/src/lib/tensors.md

+* *vector operations*: these do not change the `space` or index strucure of a tensor and can
+  be straightforwardly implemented on on the full data. All the methods described in


Suggested change

* *vector operations*: these do not change the `space` or index strucure of a tensor and can

be straightforwardly implemented on on the full data. All the methods described in

* *vector operations*: these do not change the `space` or index structure of a tensor and can

be straightforwardly implemented on the full data. All the methods described in

borisdevos · 2026-01-07T08:53:36Z

docs/src/lib/tensors.md

-  dedicated implementation.
+  Tensor contractions correspond to a combination of some index manipulations followed by a
+  composition or multiplication of the tensors in their role as linear maps. Tensor
+  contractions are however of such important and frequency that they require a dedicated


Suggested change

contractions are however of such important and frequency that they require a dedicated

contractions are however of such importance and frequency that they require a dedicated

borisdevos · 2026-01-07T08:55:46Z

docs/src/lib/tensors.md

+  between tensor spaces. The factorisations are applied as ordinary matrix factorisations to
+  the matrix blocks associated with the coupled charges.


Suggested change

between tensor spaces. The factorisations are applied as ordinary matrix factorisations to

the matrix blocks associated with the coupled charges.

between tensor spaces. The factorizations are applied as ordinary matrix factorizations to

the matrix blocks associated with the coupled charges.

There's another "factorisation" in the line above

borisdevos · 2026-01-07T08:55:58Z

docs/src/lib/tensors.md

-entire range of MatrixAlgebraKit functions can be called.
-Factorizing a tensor according to a different partition of the indices is possible
-by prepending the factorization step with an explicit call to [`permute`](@ref) or [`transpose`](@ref).
+The factorisation methods are powered by


Suggested change

The factorisation methods are powered by

The factorization methods are powered by

borisdevos · 2026-01-07T08:58:13Z

docs/src/man/intro.md

 to the dual space of ``W``. This simple example introduces two new concepts.

 1.  Typical vector spaces can appear in the domain and codomain in different related forms,
    e.g. as normal space or dual space. In fact, the most generic case is that every vector


Suggested change

e.g. as normal space or dual space. In fact, the most generic case is that every vector

e.g. as normal spaces or dual spaces. In fact, the most generic case is that every vector

borisdevos · 2026-01-07T09:00:10Z

docs/src/man/tutorial.md

-which we can obtain by typing `⊗` (i.e. `\otimes+TAB`), although for simplicity also the
-usual multiplication sign `*` does the job. Note also that `A` is printed as an instance of
-a parametric type `TensorMap`, which we will discuss below and contains `Tensor`.
+Note that we entered the tensor size not as plain dimensions, by specifying the vector space


Suggested change

Note that we entered the tensor size not as plain dimensions, by specifying the vector space

Note that we entered the tensor size not as plain dimensions, but by specifying the vector space

borisdevos · 2026-01-07T09:02:25Z

docs/src/man/tutorial.md

 i.e. `ℝ^n` can also be created without Unicode using the longer syntax `CartesianSpace(n)`.
-It is subtype of `ElementarySpace`, with a standard (Euclidean) inner product
-over the real numbers. Furthermore,
+It is subtype of `ElementarySpace`, with a standard (Euclidean) inner product over the real


Suggested change

It is subtype of `ElementarySpace`, with a standard (Euclidean) inner product over the real

It is a subtype of `ElementarySpace` with a standard (Euclidean) inner product over the real

borisdevos · 2026-01-07T09:04:29Z

docs/src/man/tutorial.md

+numbers. Furthermore,

 ```@repl tutorial
 W = ℝ^3 ⊗ ℝ^2 ⊗ ℝ^4


Line 60 has a typo: Given that they ~~are~~ behave as vectors, they also...

borisdevos · 2026-01-07T09:06:59Z

docs/src/man/tutorial.md

+TensorKit.jl reexports the `@tensor` macro

 ```@repl tutorial
 @tensor D[a,b,c,d] := A[a,b,e] * B[d,c,e]


Line 105 and onwards uses the outdated tsvd function to illustrate a factorization, so the REPL tutorial is just showing errors. This continues to line 141 and 177-183.

borisdevos · 2026-01-07T11:08:50Z

docs/src/man/tensormanipulations.md

+meaning to a direct sum of tensor product spaces.
+
+Time for some more examples:
+```@repl tensors


This REPL is failing because TensorKit isn't exported, and t and V1 aren't defined

borisdevos · 2026-01-07T11:10:32Z

docs/src/man/tensormanipulations.md

+in a new destination tensor, but just modifies the tensor `t` in place. Twisting several
+indices simultaneously can be obtained by using the defining property
+
+``θ_{V⊗W} = τ_{W,V} ∘ (θ_W ⊗ θ_V) ∘ τ_{V,W} = (θ_V ⊗ θ_W) ∘ τ_{W,V} ∘ τ_{V,W}.``


Suggested change

``θ_{V⊗W} = τ_{W,V} ∘ (θ_W ⊗ θ_V) ∘ τ_{V,W} = (θ_V ⊗ θ_W) ∘ τ_{W,V} ∘ τ_{V,W}.``

``θ_{V⊗W} = τ_{W,V} ∘ (θ_W ⊗ θ_V) ∘ τ_{V,W} = (θ_V ⊗ θ_W) ∘ τ_{W,V} ∘ τ_{V,W},``

borisdevos · 2026-01-07T11:11:00Z

docs/src/man/tensormanipulations.md

+have no effect. Let us start with some examples, in which we illustrate that, albeit
+`permute` might act highly non-trivial on the fusion trees and on the corresponding data,
+after conversion to a regular `Array` (when possible), it just acts like `permutedims`
+```@repl tensors


Same as above

borisdevos · 2026-01-07T11:12:38Z

docs/src/man/tensormanipulations.md

+BraidingStyle(sectortype(t))
+```
+Note that `transpose` acts like one would expect on a `TensorMap{T,S,1,1}`. On a
+`TensorMap{TS,N₁,N₂}`, because `transpose` replaces the codomain with the dual of the


Suggested change

`TensorMap{TS,N₁,N₂}`, because `transpose` replaces the codomain with the dual of the

`TensorMap{T,S,N₁,N₂}`, because `transpose` replaces the codomain with the dual of the

borisdevos · 2026-01-07T11:13:03Z

docs/src/man/tensormanipulations.md

+Note that `transpose` acts like one would expect on a `TensorMap{T,S,1,1}`. On a
+`TensorMap{TS,N₁,N₂}`, because `transpose` replaces the codomain with the dual of the
+domain, which has its tensor product operation reversed, this in the end amounts in a
+complete reversal of all tensor indices when representing it as a plain mutli-dimensional


Suggested change

complete reversal of all tensor indices when representing it as a plain mutli-dimensional

complete reversal of all tensor indices when representing it as a plain multi-dimensional

borisdevos · 2026-01-07T11:14:46Z

docs/src/man/tensormanipulations.md

+ss_tensor_contraction).
+
+To show the effect of `twist`, we now consider a type of sector `I` for which
+`BraidingStyle{I} != Bosonic()`. In particular, we use `FibonacciAnyon`. We cannot convert


Suggested change

`BraidingStyle{I} != Bosonic()`. In particular, we use `FibonacciAnyon`. We cannot convert

`BraidingStyle(I) != Bosonic()`. In particular, we use `FibonacciAnyon`. We cannot convert

borisdevos · 2026-01-07T11:15:07Z

docs/src/man/tensormanipulations.md

+the resulting `TensorMap` to an `Array`, so we have to rely on indirect tests to verify our
+results.
+
+```@repl tensors


borisdevos · 2026-01-07T11:16:18Z

docs/src/man/tensormanipulations.md

+Other factorizations that are provided by TensorKit.jl are orthogonal or unitary in nature,
+and thus always require a Euclidean inner product. However, they don't require equal domain
+and codomain. Let us first discuss the *singular value decomposition*, for which we define
+and export the methods [`tsvd`](@ref) and `tsvd!` (where as always, the latter destroys the


tsvd mentioned. In general this section is outdated and doesn't mention MAK

borisdevos · 2026-01-07T11:24:14Z

docs/src/man/sectors.md

+(only if ``a == \overline{a}``) are encoded in the F-symbol. They are obtained as
+[`dim(a)`](@ref), [`frobenius_schur_phase(a)`](@ref) and
+[`frobenius_schur_indicator(a)`](@ref). These functions have default definitions which
+compute the requested data from `Fsymbol(a, conj(a), a, a, one(a), one(a))`, but they can be


Suggested change

compute the requested data from `Fsymbol(a, conj(a), a, a, one(a), one(a))`, but they can be

compute the requested data from `Fsymbol(a, dual(a), a, a, unit(a), unit(a))`, but they can be

I think it's fine to not make the discrepancy between unit and left/rightunit

borisdevos · 2026-01-07T11:24:42Z

docs/src/man/sectors.md

+overloaded in case the value can be computed more efficiently. The same holds for related
+fusion manipulations such as the B-symbol, which is obtained as [`Bsymbol(a, b, c)`](@ref).
+Finally, the twist associated with a sector `a` is obtained as [`twist(a)`](@ref), which
+also has a default implementation in terms of the R-symbol. In addition, tThe function


Suggested change

also has a default implementation in terms of the R-symbol. In addition, tThe function

also has a default implementation in terms of the R-symbol. In addition, the function

borisdevos · 2026-01-07T12:43:27Z

docs/src/man/sectors.md

-Groups themselves are abstract types without any functionality (at least for now). We also
-provide a number of convenient Unicode aliases. These group names are probably self-
-explanatory, except for `CU₁` which is explained below.
+Groups themselves are abstract types without any functionality (at least for now). However,


Mention GroupElement sector here perhaps?

borisdevos · 2026-01-07T12:44:48Z

docs/src/man/sectors.md

-automatic conversion and pretty printing are provided, as illustrated by the following
-example
+you should not worry about the details of `HalfInt` and additional methods for automatic
+conversion and pretty printing are provided, as illustrated by the following example
 ```@repl sectors
 Irrep[U₁](0.5)
 U1Irrep(0.4)
 U1Irrep(1) ⊗ Irrep[U₁](1//2)
 u = first(U1Irrep(1) ⊗ Irrep[U₁](1//2))
 Nsymbol(u, conj(u), one(u))


Suggested change

Nsymbol(u, conj(u), one(u))

Nsymbol(u, dual(u), unit(u))

borisdevos · 2026-01-07T12:45:58Z

docs/src/man/sectors.md

+WignerSymbols.jl is able to generate the required data in arbitrary precision, we have
+explicitly restricted the scalar type of `SU2Irrep` to `Float64` for efficiency.
+
+The following example illustrates the usage of `SU2Irrep`
 ```@repl sectors
 s = SU2Irrep(3//2)
 conj(s)


Suggested change

conj(s)

dual(s)

borisdevos · 2026-01-07T12:47:50Z

docs/src/man/sectors.md

-However, because we also allow for half integer representations, we refer to it as
-`Irrep[CU₁]` or `CU1Irrep` in full.
+Other non-abelian groups for which the irreps are implemented are the dihedral groups
+``\mathsf{D}_N``, and the semidirect product ``\mathsf{U}₁ ⋉ ℤ_2``. In the context of


Suggested change

``\mathsf{D}_N``, and the semidirect product ``\mathsf{U}₁ ⋉ ℤ_2``. In the context of

``\mathsf{D}_N``, the alternating group of order 4 ``\mathsf{A}_4``, and the semidirect product ``\mathsf{U}₁ ⋉ ℤ_2``. In the context of

borisdevos · 2026-01-07T12:48:17Z

docs/src/man/sectors.md

+``\mathsf{D}_N``, and the semidirect product ``\mathsf{U}₁ ⋉ ℤ_2``. In the context of
+quantum systems, the latter occurs in the case of systems with particle hole symmetry and
+the non-trivial element of ``ℤ_2`` acts as charge conjugation ``C``. It has the effect of
+interchaning ``\mathsf{U}_1`` irreps ``n`` and ``-n``, and turns them together in a joint


Suggested change

interchaning ``\mathsf{U}_1`` irreps ``n`` and ``-n``, and turns them together in a joint

interchanging ``\mathsf{U}_1`` irreps ``n`` and ``-n``, and turns them together in a joint

borisdevos · 2026-01-07T12:49:55Z

docs/src/man/sectors.md

+interchaning ``\mathsf{U}_1`` irreps ``n`` and ``-n``, and turns them together in a joint
+2-dimensional index, except for the case ``n=0``. Irreps are therefore labeled by integers
+``n ≧ 0``, however for ``n=0`` the ``ℤ₂`` symmetry can be realized trivially or
+non-trivially, resulting in an even and odd one-dimensional irrep with ``\mathsf{U})_1``


Suggested change

non-trivially, resulting in an even and odd one-dimensional irrep with ``\mathsf{U})_1``

non-trivially, resulting in an even and odd one-dimensional irrep with ``\mathsf{U}_1``

borisdevos · 2026-01-07T12:52:19Z

docs/src/man/sectors.md

+By default, none of the groups mentioned above have a reprenenstation theory for which
+`FusionStyle(I) == GenericFusion()`, i.e. where fusion mulitplicities are required. An
+example where this does appear is for the irreps of `SU{N}` for `N>2`. Such sectors are
+supported through


Suggested change

By default, none of the groups mentioned above have a reprenenstation theory for which

`FusionStyle(I) == GenericFusion()`, i.e. where fusion mulitplicities are required. An

example where this does appear is for the irreps of `SU{N}` for `N>2`. Such sectors are

supported through

Of the abovementioned groups, only ``mathsf{A}_4`` has a representation theory for which

`FusionStyle(I) == GenericFusion()`, i.e. where fusion multiplicities are required. Another

example where this does appear is for the irreps of `SU{N}` for `N>2`. Such sectors are

supported through

borisdevos · 2026-01-07T12:53:19Z

docs/src/man/sectors.md

+sectors are obtained using the binary operator `⊠`, which can be entered as `\boxtimes`+TAB.
+The resulting type is called [`ProductSector`](@ref), which simply wraps the individual
+sectors, but knows how to combine their fusion and braiding data correctly. First some
+examples
 ```@repl sectors
 a = Z3Irrep(1) ⊠ Irrep[U₁](1)
 typeof(a)


A couple of conjs and ones here below should be replaced by dual and unit, respectively.

borisdevos · 2026-01-07T12:53:58Z

docs/src/man/sectors.md

+constructed by giving a number of arguments, where the first argument is used to construct
+the first sector, and so forth. Furthermore, for representations of groups, we also enabled
+the notation `Irrep[ℤ₃ × CU₁]`, with `×` obtained using `\times+TAB`. However, this is
+merely for convience, as `Irrep[ℤ₃] ⊠ Irrep[CU₁]` is not a subtype of the abstract type


Suggested change

merely for convience, as `Irrep[ℤ₃] ⊠ Irrep[CU₁]` is not a subtype of the abstract type

merely for convenience, as `Irrep[ℤ₃] ⊠ Irrep[CU₁]` is not a subtype of the abstract type

borisdevos · 2026-01-07T12:58:49Z

docs/src/man/sectors.md

+multi-fusion categories, where the sectors (simple objects) are organized in a matrix-like
+structure and thus have an additional row and column index. Fusion between sectors is only
+possible when the row and column indices match appropriately; otherwise the fusion product
+is empty. In this structure, the different groups of "diagonal" sectors define separate


Is there a better word than "group" that can be used in this and the following sentence?

Jutho · 2026-01-07T22:05:18Z

Thanks for the heroic effort @borisdevos , I will try to process all these comments tomorrow.

Jutho · 2026-01-07T22:05:51Z

Also, any general comments? What do you think of the new structure of the manual? Is it an improvement?

borisdevos · 2026-01-08T08:05:41Z

It's a global improvement in my opinion. If I had to complain about some stylistic choice, there are certain paragraphs in the docs where a bunch of methods/properties are explained back-to-back, which can be bothersome to read through (although I don't know how often people really read paragraphs from start to finish and just ctrl+f words). In my opinion, one of the best-written parts is the fusion tree manipulations subsection, but maybe I'm just a big fan of lists.

Another small remark: some paragraphs in the category theory introduction are also tough to read because there's some inconsistency with the maths written within the paragraph; some of it is not in some latex equation environment. Not a huge gripe, since this part is optional to read.

But again, the pros outweigh these minor cons heavily, and the content remains rich and descriptive. I actually learnt/relearnt a lot going through the docs again 😄.

lkdvos · 2026-01-08T09:37:32Z

docs/src/man/spaces.md

+value of `isdual`) as [`V1 ⊕ V2`](@ref), where `⊕` is obtained by typing `\oplus`+TAB.
+[`zerospace(V)`](@ref) corresponds to the identity or zero element with respect to this
+direct sum operation, i.e. it corresponds to a zero-dimensional space. Furthermore,
+[`unitspace(V)`] (@ref) applied to an elementary space returns a one-dimensional space, that


Suggested change

[`unitspace(V)`] (@ref) applied to an elementary space returns a one-dimensional space, that

[`unitspace(V)`](@ref) applied to an elementary space returns a one-dimensional space, that

lkdvos · 2026-01-08T09:38:17Z

docs/src/man/spaces.md

+direct sum operation, i.e. it corresponds to a zero-dimensional space. Furthermore,
+[`unitspace(V)`] (@ref) applied to an elementary space returns a one-dimensional space, that
+is isomorphic to the scalar field underlying the space itself. Finally, we have also
+introduced the non-standard convention `V1 ⊖ V2` (obtained by typing `\ominus`+TAB.) in


Suggested change

introduced the non-standard convention `V1 ⊖ V2` (obtained by typing `\ominus`+TAB.) in

introduced the non-standard convention [`V1 ⊖ V2`](@ref) (obtained by typing `\ominus`+TAB.) in

lkdvos · 2026-01-08T10:10:28Z

docs/src/man/gradedspaces.md

I think throughout this file the header level of the sections is 3 instead of 2, which makes them not appear in the page list in the sidebar.

lkdvos · 2026-01-08T10:10:39Z

docs/src/man/fusiontrees.md

I think throughout this file the header level of the sections is 3 instead of 2, which makes them not appear in the page list in the sidebar.

lkdvos · 2026-01-08T10:29:01Z

I tried briefly skimming through the updates to just give some global comments, since it is a bit hard to interleave these/not duplicate the things @borisdevos has already marked (Thanks for the huge amount of work @borisdevos !!!)
I can then read a bit more in detail once these comments have been incorporated.

Considering the markdown formatting, I have also been advocating to indeed use a more "LaTeX" style for line breaks as well.
The lack of good markdown formatter is one good argument, but I think it is incredibly hard to figure out what the actual git diff is if entire paragraphs have to be changed/reflowed due to the introduction of a single longer word.
Additionally, github suggestions in text like this also does not work very well with linebreak limits, so in the long run I would simply use the rule that for text, every sentence is on its own line.
I'm okay with splitting up longer sentences on multiple different lines, but in general it tends to be language-wise better to then simply split up the sentence itself to begin with...
Ideally, we should just at some point decide to do this and have a single PR that implements it everywhere, so we can then spot the git diffs more easily.

I definitely like the division in more subpages, large pages make it quite hard to quickly jump to the wanted sections and to lose track of what is going on!

One suggestion I have is about the order of these pages in the manual section.
I think the main thing that feels slightly off to me is having Vector Spaces before the symmetries and sectors, and only then proceeding to Graded Spaces.
I can see the appeal of introducing a number of methods and concepts without the burden of the symmetries, and I like that idea.
Currently however, I feel like the Vector Spaces section isn't really a simplification of the concepts, and is still rather mathematically inclined both in language and concepts.
It seems also like some of the methods that are mentioned there are somewhat hard to illustrate, mostly because ComplexSpace does not have enough structure to show what is going on or why we need these methods to begin with.
I think that since most of our language is still quite mathematical in that section, it might turn out to be easier in the long run to simply bite through the sour apple (😀) and merge graded spaces and vector spaces together, after introducing sectors and symmetries, and then going to fusion trees, and finally tensors and tensor manipulations.

Co-authored-by: Boris De Vos <143942306+borisdevos@users.noreply.github.com>

Jutho added 2 commits December 28, 2025 23:51

updating sectors part 1

914e737

major doc restructuring and update

3c49b23

fix setup block and do format after all

f8235d5

Jutho added the documentation label Jan 6, 2026