# Knots and Links

®ina; offers native support for knots and links. ®ina; collectively refers to all such objects as links: a link may have multiple components, or just one component (i.e., a knot), or zero components (i.e., the empty link).

A link is stored using a link diagram, which consists of `n` crossings and 2`n` strands that connect them, possibly with some additional unknot components that have no crossings at all.

®ina; supports both classical and virtual link diagrams:

- Classical link diagrams are the typical planar diagrams that one encounters when first studing knot theory. These describe links in the 3-sphere, and such links are considered to be equivalent under ambient isotopy.

  Although classical link diagrams are planar, ®ina; considers these diagrams to be embedded in the &s2; (not the plane). In particular, ®ina; does not keep track of which cell is the “outer” cell of the diagram.

- Virtual link diagrams remove the requirement for the diagram to be planar. Instead a virtual link diagram may be embedded in some arbitrary orientable surface `S`. This describes a link in the thickened surface `S` × I, and such links are considered to be equivalent under ambient isotopy, orientation-preserving homeomorphisms of `S`, and the addition and/or removal of empty handles from `S`.

Links in ®ina; are oriented. This means that ®ina; keeps track of a “direction of travel” around each component of the link. ®ina; also maintains an orientation of the surface containing the link diagram (i.e., &s2; for a classical diagram, or the orientable surface `S` for a virtual diagram), which means there is a well-defined notion of left versus right, and positive versus negative crossings.

## Creation

The easiest way to create a new link is via the Packet Tree New Knot or Link menu item (or the corresponding toolbar button).

You will be asked what type of link to create (see the drop-down box below). Here we walk through the various options.

### Example Knots and Links

Like triangulations, ®ina; offers a selection of ready-made sample knots and links which you can use to experiment with ®ina;. Simply select an example from the list provided and ®ina; will build the corresponding link for you.

You can see many more examples by looking through the prime knot census, which is shipped as one of ®ina;'s example data files. Select File Open Example Prime Knots from the menu.

### Text Codes

This will reconstruct a link diagram from one of several common text codes.

Be aware: some types of codes only support single-component knots (not multiple-component links), and some types of codes only support classical link diagrams (not virtual link diagrams) – see below for details. If you need all of these features (multiple components and/or virtual diagrams), then good choices are knot/link signatures or planar diagram codes.

The codes that ®ina; understands include:

- ®ina;'s own knot/link signatures: These are compact sequences of letters, digits and/or punctuation that uniquely identify a link diagram up to combinatorial isomorphism. Here combinatorial isomorphism includes relabelling the crossings and/or components, reflecting the entire diagram, rotating the entire diagram, and/or reversing individual link components.

  An example is `dabcabcv-`, which represents the trefoil.

  Knot/link signatures played a significant role in the 19-crossing knot tabulation bib-burton-knots. They support both classical and virtual link diagrams, and they support all links with fewer than 64 components.

- Classical Gauss codes: These are sequences of integers that encode the crossings that you pass through as you traverse the knot from an arbitrary starting point. Crossings are numbered consecutively from 1 to `n` (but in any order), and each crossing is written as a positive or negative integer according to whether you pass over or under it.

  An example of a Gauss code is `1 -2 3 -1 2 -3`, which represents the trefoil.

  Classical Gauss codes are commonly used in the literature. Be aware that they do not specify the orientation of the diagram, and (more importantly) for composite knots they may not even uniquely define the topology of the knot. If this is a problem, consider using either oriented or signed Gauss codes, or knot/link signatures instead.

  In ®ina;, classical Gauss codes only support knots (not multiple-component links), and they only support classical (not virtual) knot diagrams.

- Oriented Gauss codes: These likewise encode the crossings that you pass through as you traverse the knot, but with more precise information than a classical Gauss code. Again the crossings are numbered consecutively from 1 to `n` (but in any order); each crossing is then written with a sign (`+` or `-`), an arrow (either less-than or greater-than), and a positive integer (which identifies the crossing). The sign indicates whether you pass over (`+`) or under (`-`) the crossing, and the arrow indicates whether the other strand of the crossing passes from right-to-left (`<`) or left-to-right (`>`).

  An example is `+>1 -<2 +>3 -<1 +>2 -<3`, which represents the left-hand trefoil.

  Oriented Gauss codes were introduced by Andreeva et al., and are described as part of their Book Knot Simplifier. Unlike classical Gauss codes, they preserve the orientation of the diagram, and they correctly identify the topology of composite knots.

  In ®ina;, oriented Gauss codes support both classical and virtual diagrams. However, they only support knots (not multiple-component links).

- Signed Gauss codes: Like oriented Gauss codes, these encode the crossings that you pass through as you traverse the knot but with more precise information than a classical Gauss code. Once more the crossings are numbered consecutively from 1 to `n` (but in any order); each crossing is then written with a letter (`O` or `U`), a positive integer (which identifies the crossing), and a sign (`+` or `-`). This time the letter indicates whether you pass over (`O`) or under (`U`) the crossing, and the sign indicates whether the crossing is positive or negative. There are no spaces in the code at all.

  An example is `U1+O2+U3-O4-U2+O1+U4-O3-`, which represents the figure eight knot.

  Oriented Gauss codes were introduced by Kauffman bib-kauffman-virtual. Like oriented Gauss codes (and unlike classical Gauss codes), they preserve the orientation of the diagram, and they correctly identify the topology of composite knots.

  In ®ina;, signed Gauss codes support both classical and virtual diagrams. However, they only support knots (not multiple-component links).

- Dowker-Thistlethwaite notation: This is essentially a more streamlined variant of classical Gauss codes. It has played an important historical role in knot tabulation; see Adams bib-adams-knotbook for some history and also a precise description of the format.

  ®ina; understands both the numerical and alphabetical variants of Dowker-Thistlethwaite notation. The numerical variant involves a sequence of `n` even signed integers. The alphabetical variant transforms this into a compact text string by replacing the positive integers `2`,`4`,`6`,… with lower-case letters `a`,`b`,`c`,…, and replacing the negative integers `-2`,`-4`,`-6`,… with upper-case letters `A`,`B`,`C`,…. The alphabetical variant can only be used to describe knots with 26 crossings or fewer.

  Examples are `4 6 2` or `bca`, both of which represent the trefoil.

  Like classical Gauss codes, Dowker-Thistlethwaite notation does not specify the orientation of the diagram, and (more importantly) for composite knots may not uniquely define the topology of the knot. If this is a problem, consider using either oriented or signed Gauss codes, or knot/link signatures instead.

  In ®ina;, Dowker-Thistlethwaite notation only supports knots (not multiple-component links), and only supports classical (not virtual) knot diagrams.

- Planar diagram codes: These are sequences of 4-tuples that encode the local connections around each crossing. Unlike the other code types described here, planar diagram codes can encode multiple-component links.

  In a planar diagram code for a link with `n` crossings, the strands are numbered 1,…,2`n`. Each 4-tuple represents a single crossing, and lists the four strands that meet at that crossing in counter-clockwise order, beginning with the incoming lower strand. ®ina; will number the crossings 0,…,(`n`-1) in the same order as the tuples are presented.

  An example of a planar diagram code is `[[1,4,2,5], [3,6,4,1], [5,2,6,3]]`, which represents the left-hand trefoil.

  You may separate the integers with any combination of whitespace, commas, round/square/curly brackets, and/or the special symbols `PD`, `X`, `Xp`, `Xm` or `P` (these symbols appear in other sources, but have no special meaning for ®ina;). So, for example, the left-hand trefoil above could instead be presented as `PD[X[1,5,2,4], X[3,1,4,6], X[5,3,6,2]]`, or just `1 5 2 4 3 1 4 6 5 3 6 2`.

  Planar diagram codes are used in the Knot Atlas (for example). They have two limitations: they cannot represent zero-crossing unknot components; also, if the link has a component that consists entirely of over-crossings (i.e., an unknot placed “on top” of the diagram) then the orientation of that component is not uniquely determined.

  In ®ina;, planar diagram codes support both classical and virtual link diagrams, and they support both knots and multiple-component links.

If you already have a knot or link and you wish to view these different text codes, you can do this through the codes tab.

Knot/link signatures and Dowker-Thistlethwaite notation are both case sensitive! Be sure that you are entering upper-case and lower-case correctly (or better, copy and paste the text using the clipboard if you can).

### Torus Links

®ina; can create a new torus link with the given parameters (`p`, `q`). This essentially involves drawing a (`p`, `q`) curve on an unknotted torus in 3-space and then removing the torus.

The parameters `p` and `q` must be non-negative integers. They do not need to be coprime: if their greatest common divisor is `d` > 1 then the result will be a link with `d` components.

You do not need to separate the lens space parameters with commas; any punctuation, or even just spaces, will suffice.

### Whitehead Doubles

®ina; can build the Whitehead double of some other knot `K`. This involves creating two parallel copies of `K` using the Seifert framing, and then cutting open these two copies and re-connecting them using a clasp. ®ina; will use positive crossings for the clasp.

To do this, select `K` in the Source drop-down box. This should be some knot that you already have in your data file. Note that ®ina; can only build the Whitehead double of a knot, not a multiple-component link.

If you already have the source knot `K` open for viewing, another way to create its Whitehead double is to select Knot / Link Build Whitehead Double from the menu. The Whitehead double will be added as a new knot directly beneath `K` in the packet tree.

### Parallel Cables

®ina; can build a new link containing &vark; cables of some other link `L`, all parallel to each other via a chosen framing. This will effectively:

- treat each component of the original link `L` as a ribbon, using the chosen framing;

- create &vark; parallel copies of `L`, following each other side-by-side along these ribbons.

To do this:

- Select `L` in the Source drop-down box. This should be some knot or link that you already have in your data file.

- Enter the number of cables &vark;, which should be an integer greater than one (but not too large—see the warning below).

- Choose the framing to use. The options are:

  Seifert framing

  This framing is a property of the underlying link (i.e., it does not depend on your specific choice of link diagram). One way to imagine it is to construct a Seifert surface (an orientable surface embedded in the 3-sphere whose boundary is the link), and then place the ribbons so that they sit flat upon this surface.

  Another way to imagine it is purely algebraic: for each component &varC; of the link, each edge of the corresponding ribbon follows a curve with trivial homology in the complement of the knot &varC;.

  Blackboard framing

  Here each ribbon sits flat in the plane of the link diagram, with no twists. This framing depends on the specific link diagram that you are using.

The parallel cables construction can generate an enormous number of crossings. If you create &vark; cables then you will multiply the number of crossings in the source link by &vark;2, and if you chose the Seifert framing then there may be even more crossings due to twists in the ribbons. Use a large &vark; at your peril!

If you already have the source link `L` open for viewing, another way to create parallel cables of `L` is to select Knot / Link Build Parallel Cables… from the menu. The parallel cables will be added as a new link directly beneath `L` in the packet tree.

## Analysis

You can view a variety of information about the link diagram, as well as topological invariants of the link itself, by stepping through the different tabs in the link viewer. Here we talk through the different kinds of information and invariants on offer.

### Crossings and Components

At the top of each link viewer is a header, which includes: whether the link is alternating; the number of link components (or the word “knot” to indicate just one); and the number of crossings, including how many are positive and negative.

This header is circled in red below.

If the link diagram is virtual (not classical), then the header will contain a second line indicating:

- The virtual genus of the diagram. This is the smallest genus of orientable surface in which the diagram embeds. Note that this is a property of the link diagram, not an invariant of the link itself.

- The odd writhe, or self-linking number. This is an invariant of virtual knots (but not links), which sums the signs of all odd crossings. A crossing `c` is odd if, when traversing the knot, we pass through an odd number of crossings between the over-strand and the under-strand of `c`.

  The odd writhe is not shown for multiple-component links. For classical knots, the odd writhe is always zero.

The Crossings tab shows the details of the individual crossings and components that make up the link. ®ina; numbers crossings 0,1,2,…, and likewise for components.

For each component of the link, there will be a box beneath the Crossings tab showing the crossings that you visit in order as you traverse the link component from an arbitrary starting point. There are two different ways that you can view this information (with a drop-down box to switch between them):

Pictures

Each crossing will be shown visually as a pair of arrows, one crossing over the other. One arrow will be a solid colour, and will run horizontally from left to right; this is the part of the link that you are traversing. The other arrow will be grey, and will run vertically (either up or down); this is the part of the link that you are passing over or under. The crossing number will be written in the top-right corner beside the arrows.

For each crossing, the arrow that you are traversing will be coloured blue for a positive crossing, or yellow for a negative crossing. (This is just a visual aid, and is not strictly necessary; you can already tell the sign of the crossing from the arrangement of the arrows.)

Crossings are visited in order from left to right along each row of the display, one row at a time (i.e., the same way that you would read English text in a book).

Because the arrows you traverse always run from left to right, you can imagine the individual crossings as being attached together in the order that they are displayed. In other words, you can picture the link component as a long arrow running from left to right through the individual crossings (and then wrapping around to the next line each time it reaches the right-hand edge of the window). Of course this picture breaks down once you revisit the same crossing for a second time.

Text

Each crossing will be shown as a number with a plus or minus sign attached. The number indicates which crossing you are passing through, and the sign indicates whether it is a positive or negative crossing. The sign will appear as a superscript if you are passing over the crossing, or a subscript if you are passing under.

As before, crossings are visited in order from left to right along each row, one row at a time. Also as before, positive crossings will be coloured blue and negative crossings will be coloured yellow (but again the colour is just a visual aid, since you already have this information from the plus/minus sign).

### Polynomial Invariants

On the Polynomials tab, you can view several polynomial invariants of the link and of the link diagram. Which polynomials you see will depend upon whether your link diagram is classical or virtual.

The polynomials that you might see include:

Alexander (classical only)

The Alexander polynomial is a single-variable polynomial invariant. It is relatively weak, but (unlike many of the other invariants listed here) it can be computed in polynomial time.

®ina; will only compute Alexander polynomials for knots (not multiple-component links).

Jones (classical and virtual)

The Jones polynomial is a single-variable polynomial in the variable `t`, whose exponents are integers for classical knots, but whose exponents may be half-integers in other cases (depending on the number of link components and/or whether the link is virtual). You may therefore see this presented either as a polynomial in `t` or as a polynomial in √`t`.

If you have opted not to use unicode symbols, then you will see this as a polynomial in either `t` or `sqrt_t`.

®ina; can compute Jones polynomials for link diagrams with any number of components.

&homflypt; (classical only)

The &homflypt; polynomial is a two-variable polynomial with two common formulations: one in the variables (`α`, `z`) and one in the variables (`l`, `m`). These formulations give different polynomials, which are related via a simple substitution. ®ina; offers a pair of buttons beside the &homflypt; polynomial for you to choose which formulation is displayed.

®ina; can compute &homflypt; polynomials for link diagrams with any number of components.

Kauffman bracket (classical and virtual)

The Kauffman bracket is a property of the link diagram, not an invariant of the link, and is related to the Jones polynomial by a simple substitution. See Adams bib-adams-knotbook for a simple combinatorial introduction to the Kauffman bracket and the Jones polynomial.

®ina; can compute Kauffman brackets for link diagrams with any number of components.

Affine index (virtual only)

The affine index polynomial is a single-variable polynomial invariant that is relatively weak, but which nevertheless provides some useful information for virtual knots. Its main advantage is that it is extremey fast to compute even for large knot diagrams (the computation runs in very small polynomial time).

®ina; will only compute affine index polynomials for virtual knots (not multiple-component virtual links).

The affine index polynomial is not shown at all for classical link diagrams, since in the classical case the affine index polynomial is always zero.

Arrow (virtual only)

The arrow polynomial enhances the Kauffman bracket in a way that makes it more powerful for virtual links, and that makes it a true link invariant. Whereas the Kauffman bracket is a polynomial in the single variable `A`, the arrow polynomial is a polynomial in many variables (`A`, `K` 1, `K` 2, `K` 3, …).

®ina; can compute arrow polynomials for virtual link diagrams with any number of components.

The arrow polynomial is not shown at all for classical link diagrams, since in the classical case the arrow polynomial is just the Kauffman bracket with some normalisation applied.

For larger links, you may see a Calculate button instead of a polynomial. This is because many of these polynomials require exponential time to compute. In this case you will need to press the Calculate button and be prepared to wait—for most polynomials you will see the progress displayed, and you can cancel the computation if you like.

For smaller links, all of the polynomials will be computed automatically.

You can copy any of these polynomials to the clipboard by right-clicking and selecting either Copy or Copy plain text. If you press Copy then the polynomial will be copied using unicode symbols, and if you press Copy plain text then the polynomial will be copied in plain &ascii; symbols using a simple “pidgin &tex;”.

If you find the polynomial exponents hard to read (due to the subscripts being very small), you can visit ®ina;'s settings and disable unicode symbols. This will change the polynomial display to use a simple “pidgin &tex;” instead.

### Algebraic Invariants

The Algebra tab holds several smaller tabs that describe different groups associated with the link.

Currently this shows the following groups:

Knot/Link Group

This is the link group as constructed from the Wirtinger presentation (though ®ina; will typically simplify the presentation before showing it here). Each relation is some variant of the form `xy=yz`, where `y` corresponds to the upper strand at some crossing, and `x` and `z` correspond to the two sides of the lower strand at that same crossing.

- For classical links, this is isomorphic to the fundamental group of the link complement. However, it is constructed differently, and so it may have a different presentation. If you are having difficulty simplifying it, you could perhaps try working with the triangulated link complement instead.

- For virtual links, the link group could change depending upon whether you view the link from above or below the diagram (i.e., rotating the link may change the isomorphism class). For this reason, if the link diagram is virtual then you will see two groups: one as seen from above (using the classical Wirtinger presentation), and one as seen from below (obtained by switching the upper and lower strands at every crossing). The Goussarov-Polyak-Viro knot (which is one of ®ina;'s ready-made examples is a nice example of where these two groups differ.

  Note however that, for virtual links, the link group is not a particularly strong invariant. You might wish to work with the extended group instead (see below).

Extended Group

This is the extended group of the link, as defined by Silver and Williams bib-silver-extgrp. This invariant is particularly useful for virtual links, where the ordinary link group is a fairly weak invariant. However, it also yields more complex group presentations.

Like the ordinary link group, the extended group of a virtual link may change depending upon whether you view the link from above or below the diagram, and so for virtual link diagrams ®ina; will display both variants.

All groups will be presented in the same format as the fundamental group of a triangulation, and you are given the same tools to simplify them. See the section on fundamental groups for further discussion of this.

If you find the exponents in the group presentations hard to read (due to the superscripts being very small), you can visit ®ina;'s settings and disable unicode symbols. This will change the display to use a simple “pidgin &tex;” instead.

### Text Codes

The Text Codes tab allows you to export your knot or link in several text-based formats. Simply select a format from the drop-down box (indicated in the screenshot below), and the corresponding text code will be shown in the box beneath.

The codes that ®ina; can display include:

Gauss codes

This displays the classical, oriented and signed Gauss codes. Classical Gauss codes are common in the literature, but they suffer from ambiguities related to orientation; for composite knots they may not even uniquely define the topology. Oriented and signed Gauss codes solve this problem by adding a little more information.

For a more detailed description of these formats, see the section on creating knots from Gauss codes.

Currently ®ina; only displays Gauss codes for knots (not multiple component links). If your knot diagram is virtual (not classical), then ®ina; will still display all three Gauss codes; however, only the oriented and signed variants contain enough informtion to reconstruct the diagram.

Dowker-Thistlethwaite notation

Like classical Gauss codes, Dowker-Thistlethwaite notation is also common in the literature, and also suffers from ambiguities related to orientation and composite knots. Dowker-Thistlethwaite notation comes in two forms—numerical and alphabetical—and ®ina; displays both forms here.

For a more detailed discussion of Dowker-Thistlethwaite notation, see the section on creating knots from Dowker-Thistlethwaite notation.

Currently ®ina; only displays Dowker-Thistlethwaite notation for knots (not multiple component links), and only for classical (not virtual) knot diagrams. Be aware that alphabetical Dowker-Thistlethwaite notation is case-sensitive (i.e., upper-case and lower-case matters).

Knot/link signature

Knot/link signatures are ®ina;s own text-based format, and were designed to have a combinatorial uniqueness property: two link diagrams have the same signature if and only if they are combinatorially isomorphic (which includes relabelling crossings and/or components, reflecting the entire diagram, rotating the entire diagram, and/or reversing individual link components).

For a more detailed discussion of knot/link signatures, see the section on creating knots from knot/link signatures.

These signatures are supported for all links with fewer than 64 components, and they support both classical and virtual link diagrams. Be aware that knot/link signatures are case-sensitive (i.e., upper-case and lower-case matters).

Planar diagram codes

This displays the planar diagram code for the link. Planar diagram codes support multiple-component links, as well as both classical and virtual link diagrams. Their main limitations are that they cannot represent zero-crossing unknot components, and they cannot fix the orientation of a link component that consists entirely of over-crossings.

For a detailed description of planar diagram codes, see the section on creating links from planar diagram codes.

Jenkins format

This is a multiline text code described by Bob Jenkins, and used in his &homflypt; polynomial software. ®ina; can happily display the Jenkins format for multiple-component links, and for both classical and virtual link diagrams.

In this format, a link is described by a sequence of integers separated by whitespace. We assume that there are `n` crossings in the link, labelled arbitrarily as 0,1,2,…. The sequence of integers will contain, in order:

- the number of components in the link;

- for each link component:

  - the number of times you pass a crossing when traversing the component (i.e., the length of the component);

  - for each link component: two integers for each crossing that you pass in such a traversal: the crossing label, and then either +1 or -1 according to whether you pass over or under the crossing respectively;

- for each crossing:

  - the crossing label;

  - the sign of the crossing (either +1 or -1).

For all of these text codes except for Jenkins format, you can convert a text code back into a link as described in creating a new link. Be aware that the resulting link might not use the same crossing numbers, and might even be a reflection and/or reversal of the original.

For Jenkins format, ®ina;'s graphical user interface does not offer a way to convert a code back into a link; however, you can always bring up a &python; console and call the function `Link::fromJenkins()` instead.

### Associated Graphs

On the Graphs tab, you can view different graphs associated with the link diagram. These graphs are all related to the diagram graph, which is a 4-valent graph with one vertex for each crossing and edges that follow the strands of the link.

There is a drop-down box for you to choose which graph you want to see. The options are:

Tree decomposition

A tree decomposition (illustrated below) models the diagram graph using a rooted tree; you can read more about tree decompositions in the triangulations chapter. ®ina; uses these tree decompositions in its fixed-parameter tractable algorithms for the Jones and &homflypt; polynomials bib-homfly-fpt.

®ina; will display both the width and the number of bags above the tree decomposition itself.

As with triangulations, ®ina; does not guarantee to find a tree decomposition of the smallest possible width (i.e., it does not compute the precise treewidth of the diagram graph). Instead it uses fast heuristics that are found to produce low-width tree decompositions in practice.

Nice tree decomposition

This is a variant of the tree decomposition that is less concise, but more useful in practice for algorithms since it imposes very tight constraints on the relationships between parent and child bags. Again, you can read more about these in the triangulations chapter.

As with tree decompositions, ®ina; will display both the width of the nice tree decomposition and the number of bags that it contains. Typically the width will be the same as for the (plain) tree decomposition above, but the number of bags may be significantly larger (though still linear in the overall number of crossings).

### Link Complements

®ina; includes many tools for working with 3-manifold triangulations, as well as working directly with knots and links. If you want access to these 3-manifold tools, you can build a triangulation of the link complement.

The meaning of “complement” in this setting depends upon whether you are working with a classical or virtual link diagram.

- If you have a classical link diagram, then ®ina; will build an ideal 3-manifold triangulation representing the complement of your link in the 3-sphere.

  The resulting triangulation will have exactly one ideal vertex for each link component.

  If your link diagram is disconnected (in the graph-theoretical sense), then the resulting 3-manifold will be the connected sum of the complements of each connected diagram component. In particular, the resulting triangulation will always be connected.

  For classical links, the complement is a topological invariant of the link.

- If you have a virtual (non-classical) link diagram, let `S` be the smallest genus closed orientable surface in which the diagram embeds (this corresponds to the virtual genus of the diagram). Then ®ina; will build the complement of your link diagram in the thickened surface `S` × I.

  The resulting triangulation will have one ideal vertex for each link component, plus an additional two ideal vertices for the two copies of `S` on the boundary of `S` × I.

  If your link diagram is disconnected (in the graph-theoretical sense), then the surface `S` that is used will be the connected sum of the individual closed orientable surfaces that host each connected diagram component. In particular, as in the classical case, the resulting triangulation will always be connected.

  For virtual links, the complement (and indeed the genus of the surface `S`) is not a topological invariant, but instead depends upon the specific link diagram.

There are two ways you can build a link complement:

- If you select Knot / Link Complement from the menu or press the corresponding toolbar button (the first button circled above), then ®ina; will use its own implementation to create a native ®ina; triangulation of the complement. The triangulation will have access to the full suite of ®ina;'s tools for triangulations, but the meridian and longitude curves from the diagram will be forgotten.

  The Complement option is available for all link diagrams, both classical and virtual.

- If you select Knot / Link Complement Via &snappea; from the menu or press the corresponding toolbar button (the second button circled above), then ®ina; will pass the link to the &snappea; kernel to triangulate instead; the result will be a hybrid &snappea; triangulation. The peripheral curves from the diagram will be preserved in &snappea;'s data structures; however, the available tools for working with the triangulation combinatorially will be more limited. See the introduction to the chapter on &snappea; triangulations for more information on these limitations.

  The Complement Via &snappea; option is only available for classical link diagrams, not virtual diagrams.

Regardless of which method you use, the new triangulation will be inserted immediately beneath your link in the packet tree.

### Decomposition

At present ®ina; only offers very basic algorithms for decomposing links into smaller pieces. These include the following:

#### Diagram Components

If you have a link diagram that is a disjoint union of several smaller diagrams, you can split the diagram into its connected components. Here connected means that you can travel between any two parts of the diagram by following the link and/or jumping between upper and lower strands at crossings. In other words, connectivity refers to the underlying 4-valent graph, where every crossing becomes a 4-way intersection.

What this means:

- A disconnected link diagram must describe a splittable link.

- A splittable link, however, could be described by a single connected diagram component. For example, you could perform trivial type II Reidemeister moves to make the different link components overlap (thus making the entire link diagram connected).

- In general, a single diagram component could contain multiple link components.

To split a link diagram into its connected components, select Knot / Link Extract Diagram Components from the menu. You must open the link for viewing before you can do this.

®ina; will create several new links, one for each connected component of the original diagram. These will be added beneath the original in the packet tree. Your original (disconnected) link diagram will remain unchanged.

## Modification

There are several options for modifying a link diagram. Many of these can be found in the Knot / Link menu, which appears when you open a link for viewing.

If you open one link for viewing but then select another in the packet tree, all modifications will apply to the link that you have open for viewing.

### Editing Crossings

You can edit a link directly by altering its individual crossings. ®ina; gives you several ways do this, all of which will typically change the topology of the link:

Changing a crossing

This involves switching the over-strand with the under-strand; in other words, passing one strand through the other.

This operation is sometimes called switching a crossing.

Resolving a crossing

This removes the crossing entirely by chopping and splicing the over-strand and the under-strand together. Suppose the crossing originally involved strand `x` passing over strand `y`. After resolving the crossing, the section of the link that entered along `x` will exit along `y`, and the section that entered along `y` will exit along `x`. This will be done in a way that preserves orientation (i.e., the directions of the arrows).

This operation is sometimes called splicing a crossing.

Making a crossing virtual

If you are familiar with virtual link diagrams, this converts a classical crossing into a virtual crossing (one that is often marked with a small circle in diagrams on the plane).

From ®ina;'s point of view, this operation simply removes the crossing entirely, but without changing the connections between the strands. In other words, the two strands that used to pass over/under each other will now avoid each other entirely: instead the incoming and outgoing upper strands will simply merge into one, and the incoming and outgoing lower strands will likewise merge into one.

If applied to a classical link diagram, this operation will typically make the diagram virtual (since it requires adding a new handle to the surface in which the diagram embeds, which the original upper and lower strands can use to pass by one another). If applied to a virtual link diagram, it could potentially change the virtual genus, or even make the diagram classical again.

To change, resolve, or make a crossing virtual, switch to the Crossings tab, right-click on the crossing you want to modify, and choose which operation you wish to perform. (You will also see an extra option to reverse a single component.)

On computers where right-click is not supported (e.g., computers with a one-button mouse), you should use the normal secondary-click mechanism for bringing up a pop-up context menu.

### Automatic Simplification

®ina; offers a number of local moves (including the well-known Reidemeister moves) for modifying a link diagram without changing the underlying link. If you select Knot / Link Simplify from the menu or press the corresponding toolbar button, then ®ina; will use a combination of these moves to reduce the link to as few crossings as it can. This procedure is always fast and works well in many scenarios, but there is no guarantee that this will produce the fewest possible crossings: ®ina; might get stuck at a local minimum from which it cannot see how to escape.

This fast simplification process will never reflect, rotate or reverse your link.

#### Exhaustive Simplification

If ®ina; cannot simplify the link immediately using its fast heuristics, and if your link has fewer than 64 components, then it will offer to perform a slower, more exhaustive search. Press the Try harder button, as shown below:

At this point, ®ina; will begin an exhaustive search through the Reidemeister graph (this is essentially the graph that relates all diagrams of the underlying knot through Reidemeister moves):

You can stop this search at any time by pressing the Cancel button.

Since the Reidemeister graph is infinite, ®ina; will only search through intermediate knots with a certain maximum number of crossings. If this still fails, it will offer to search further, and you can press Keep trying to continue the search using larger intermediate knots than before. This cycle of ever-expanding searches will continue for as long as you like: ®ina; will only stop if you decline to keep searching, or you cancel a search while it is running, or it finds a smaller knot diagram than the one it began with.

As of ®ina; 7.4, this exhaustive simplification (like the fast simplification before it) will never reflect, rotate or reverse your link.

When searching the Reidemeister graph, both the time and memory consumption grow at a super-exponential rate relative to the number of crossings. If you continue to press Keep trying over and over, you may well run out of time or memory (or both).

If your aim is to recognise a classical knot, an alternative is to build the knot complement and then try to recognise the resulting 3-manifold instead. The 3-manifold tools in ®ina; are much richer, and in particular ®ina;'s simplification of 3-manifold triangulations works extremely well in practice. For the 141-crossing Gordian unknot, building the complement will detect unknottedness immediately, since ®ina; is typically able to reduce the complement immediately to a one-tetrahedron solid torus.

### Improving Treewidth

Instead of trying to reduce the number of crossings, you can also ask ®ina; to try to reduce the treewidth of the link diagram. Treewidth is a measure of how tree-like the underlying 4-valent model graph is, and reducing the treewidth is important because it can significantly speed up difficult computations such as Jones and &homflypt; polynomials.

To reduce the treewidth, select Knot / Link Improve Treewidth from the menu or press the corresponding toolbar button.

®ina; will begin to explore the Reidemeister graph in search of a smaller treewidth diagram, in a similar manner to the exhaustive simplification process described above. Like exhaustive simplification, ®ina; will occasionally stop and offer to expand its search; also, like exhaustive simplification, you can cancel the search at any time.

It is important to understand that ®ina; does not compute the precise treewidth of a link diagram (i.e., the minimum width of a tree decomposition), since this is an NP-hard problem. Instead it uses fast heuristics to find a low-width tree decomposition for a given diagram, and it is this “heuristic width” that will be reduced.

As with exhaustive simplification, both time and memory consumption grow at a super-exponential rate as the search expands. Also, as with exhaustive simplification, this operation could well reflect or rotate your link and/or reverse individual components.

### Reidemeister Moves

Instead of using automatic simplification, you might wish to modify your link manually one step at a time. You can do this using Reidemeister moves, which are small local modifications to the link diagram that preserve the topology of the underlying link. To perform Reidemeister moves, select Knot / Link Reidemeister Moves… from the menu or press the corresponding toolbar button.

This will bring up a box containing all the Reidemeister moves that can be performed upon your link.

For each type of move, you will be offered a drop-down list of locations at which the move can be performed. If a move is disabled (greyed out), this means there are no suitable locations in your link for that move type.

Select a move, and then press Apply to perform it. You may continue to apply one move after another. When you are done, press Close to close the Reidemeister move box.

The available moves are:

R1 twist

Introduces a small local twist in a strand of the link. Each option in the drop-down list specifies a strand (described as an arrow between two crossings), which side of the strand to twist on (left or right, as viewed when facing the direction of the arrow), and the sign of the new crossing that will appear (positive or negative).

R1 untwist

The opposite of an R1 twist. Each option in the drop-down list corresponds to a crossing where a local twist is found (this corresponds to the new crossing introduced by an R1 twist move).

R2 overlap

Takes two strands that border the same cell in the link diagram, and passes one over the other. This move comes with two drop-down lists, marked Over and Under, and you need to select your strands in this order.

First, use the Over list to choose which strand will pass over the other; each option in this list specifies both the strand (as an arrow between two crossings) and in which direction it will be pushed (left or right, as viewed when facing the direction of the arrow). This will cause the Under list to be re-filled with compatible strands that can be pushed under the first, and now you can select one of these options also.

These drop-down lists do not offer virtual R2 overlap moves (which do not require the two strands to border the same cell, and which could therefore increase the virtual genus of the diagram). If you need to perform a virtual R2 overlap move, you can always use the function `Link::r2Virtual()` in &cpppython;.

R2 separate

The opposite of an R2 overlap. Each option in the drop-down list describes a pair of crossings that are connected by a pair of strands that can be pulled apart (these correspond to the two new crossings introduced by an R2 overlap move).

R3

Passes a strand of the link over a nearby crossing. This move takes place around a triangular cell in the link diagram, and each option in the drop-down list corresponds to the three crossings that surround this triangle.

### Reflection, Rotation and Reversal

®ina; offers some simple transformations related to orientation: each of these changes will alter the link diagram, but the knot/link signature will stay the same.

- If you select Knot / Link Reflect from the menu or press the corresponding toolbar button, ®ina; will reflect your link about an axis in the plane. Each crossing will change sign (positive becomes negative and vice versa), but over-crossings will remain over-crossings, and under-crossings will remain under-crossings.

  For virtual link diagrams (which do not live in the plane), this operation effectively performs an orientation-reversing homeomorphism of the surface in which the diagram embeds. In the language of &greentables;, this is a horizontal mirror image.

- If you select Knot / Link Rotate from the menu or press the corresponding toolbar button, ®ina; will rotate your link about an axis in the plane (like turning a sheet of paper over so the back becomes visible). This means that over-crossings will become under-crossings and vice versa, but the sign of each crossing will remain the same.

  For virtual link diagrams (which do not live in the plane), we can think of the diagram as embedded in some thickened surface `S` × I. This operation effectively performs an orientation-preserving homeomorphism of `S` × I that switches the two copies of `S` on the boundary.

  Some authors refer to this operation as a flip. In the language of &greentables;, this is the composition of both a vertical and a horizontal mirror image.

- If you select Knot / Link Reverse from the menu or press the corresponding toolbar button, ®ina; will reverse the orientation (i.e., direction of traversal) of every component of your link. Both the sign (positive or negative) and the side (under or over) of each crossing will remain the same, but each component will walk through its crossings in reverse order.

For a link with multiple components, you can reverse an individual component by switching to the Crossings tab and right-clicking on any part of the component that you wish to reverse. On computers where right-click is not supported (e.g., computers with a one-button mouse), you should use the normal secondary-click mechanism for bringing up a pop-up context menu.

### Making a Link Alternating

If a link diagram is non-alternating, ®ina; can change some of its crossings in order to make the diagram alternating. (To change a crossing means to switch the upper and lower strands.) This operation will typically change the topology of the link.

To do this, select Knot / Link Make Alternating from the menu or press the corresponding toolbar button.

Your link diagram will be modified directly.

For classical link diagrams this operation will always succeed. For virtual link diagrams it might not be possible; if the diagram cannot be made alternating then ®ina; will report this and leave the diagram unchanged.

### Self Framing

To self frame a link means to add any necessary twists (i.e., Reidemeister 1 moves) to ensure that each individual component has zero writhe.

To do this, select Knot / Link Self Frame from the menu or press the corresponding toolbar button.

Your link will be modified directly.

### Building Composite Links

You can combine two links using the operation of composition. This will convert some link `L` into the composite link `L` # `M` for some other link `M` (note that `M` is allowed to be the same as `L`). The composition operation will respect the orientations (i.e., directions of traversal) of each link.

To form this composition, first open the the link `L` for editing; this is the link that you are operating on, and it will be modified directly. Then select Knot / Link Compose With… from the menu.

®ina; will ask you which other link to compose with; in other words, ®ina; will ask you for the link `M`. This second link `M` will be left unchanged (unless of course you have chosen to compose `L` with itself, which is perfectly legal and will work as expected).

The link `L` will be changed directly into the resulting composite link.

If you need control over the specific arcs in each link where the composition takes place (which matters with virtual links, for example), you will need to use the function `Link::graft()` in &cpppython;.

### Building Disjoint Unions

You can also combine two links using a disjoint union. This will convert some link `L` into the split link `L` U `M` for some other link `M` (note that `M` is allowed to be the same as `L`). Essentially, this modifies `L` by placing a copy of `M` beside it. As with composition, the disjoint union will respect the orientations (i.e., directions of traversal) of each link.

To form this union, first open the the link `L` for editing; this is the link that you are operating on, and it will be modified directly. Then select Knot / Link Insert Link… from the menu.

®ina; will ask you which other link to insert; in other words, ®ina; will ask you for the link `M`. This second link `M` will be left unchanged (unless you have chosen to insert `L` into itself, which is again legal and will work as expected).

The link `L` will be changed directly into the disjoint union `L` U `M`.