Implement the Links-Gould polynomial invariant for links

[soehms]

At the moment there doesn't seem to be any public available calculator for this invariant. We will implement it straight forward according to the definition given in A CUBIC DEFINING ALGEBRA FOR THE LINKS-GOULD POLYNOMIAL by Marin and Wagner, section 3. Calculations are done on sparse matrices over a univariate quotient polynomial ring over a two variate Laurent polynomial ring since the square-roots of a non monomial polynomial are involved. This is just necessary for the calculation. The result simplifies to a proper two variate Laurent polynomial. As the dimension of these matrices are given by 4^num_strands the performance slows down accordingly.

In a second step we could try to figure out if the approach followed in a 2013 paper of David de Witt respective a 2019 paper of Cristina Ana-Maria Anghel would improve performance.

Some examples: On an i7 CPU the calculation for three strand braids need less than a second. For four strand braids it takes between two and six seconds whereas for five strand braids between one and two minutes are needed. For example K8_1 takes one and a half minute. Braids with six strands need more than than 20 minutes (for example K10_1 22 minutes).

Component: algebraic topology

Keywords: Links-Gould polynomial knots links

Author: Sebastian Oehms

Branch/Commit: 08e3bfe

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/33798

[soehms]

Branch: u/soehms/links_gould_poly_33798

[soehms]

Commit: 73412bf

[soehms]

Author: Sebastian Oehms

[soehms]

New commits:

73412bf

33798: initial version

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

0ab620c

Merge branch 'u/soehms/links_gould_poly_33798' of trac.sagemath.org:sage into links_gould_poly_33798

[sagetrac-git]

Changed commit from 73412bf to 0ab620c

[soehms]

comment:4

I just fixed a merge conflict.

[tscrim]

comment:5

Since everything only involves square roots of the variables, wouldn't it be better to replace t_i with t_i^2? That way you can do everything in polynomial rings, which should be much faster. Afterwards you could then substitute back.

[soehms]

comment:6

Replying to @tscrim:

Since everything only involves square roots of the variables, wouldn't it be better to replace t_i with t_i^2? That way you can do everything in polynomial rings, which should be much faster. Afterwards you could then substitute back.

Maybe I don't understand your idea exactly. I've tried to use a quotient ring over a three variate polynomial ring the third variable of which corresponding to the term abbreviated Y in Ivan Marin's paper. At the moment I don't have access to my notes about that, since I'm on vacation. But this was even slower than using the symbolic ring.

[tscrim]

comment:7

Replying to @soehms:

Replying to @tscrim:

Since everything only involves square roots of the variables, wouldn't it be better to replace t_i with t_i^2? That way you can do everything in polynomial rings, which should be much faster. Afterwards you could then substitute back.

Maybe I don't understand your idea exactly. I've tried to use a quotient ring over a three variate polynomial ring the third variable of which corresponding to the term abbreviated Y in Ivan Marin's paper.

I am not suggesting that. In the description, you say you use SR since for the Laurent polynomial ring variables "x,y", you use x^1/2 and y^1/2 in the computations. I am just saying use the variables t₀ = x^1/2 and t₁ = y^1/2 for the computations to avoid SR. Then in the final computation, you just rescale all of the exponents by 1/2 since the result is a polynomial. Although we could just output with the squared variables with a .. WARNING:: indicating the change in convention.

At the moment I don't have access to my notes about that, since I'm on vacation. But this was even slower than using the symbolic ring.

No problem. Enjoy your vacation.

I would have the internal cached method use fixed variable names and then do a substitution for different user input to not redo the computation just because the variable names change.

Also, typo: beeing.