Revision of the knot theory colorings method

[soehms]

The following issue has been reported by Chuck Livingston to me:

sage: K9_15 = Knots().from_table(9, 15)
sage: K9_15.colorings(13)
[]
sage: K9_15.determinant()
39

Since 13 divides the determinant of the knot 156 colorings are expected. While analyzing this issue, I found that the implementation (done in #21863) does not match the definition of Fox n-colorings given in the listed references on Wikipedia and in Chuck's book.

The name coloring maybe misleading here: The number n does not refer to the number of (arbitrary) colors to be used. It can be interpreted as the size of a fixed color palette. Mathematically, the colors correspond to elements of the n-th dihedral group D_n whose rotations (multiplied with the generating transvection) form the color palette. A coloring corresponds to a group homomorphism from the fundamental group F of the knot to D_n. If one interprets the arcs of the knot as the generators of F, their colors correspond to their images in D_n.

Here are some lines in the current code that do not meet this definition:

1. Changing n to the next prime number:

        p = next_prime(n - 1)

2. Restriction of n to the number of different colors used:

            if len(colors) == p:

3. Change color values:

                colors = {b: a for a, b in enumerate(colors)}
                res.add(tuple(colors[c] for c in coloring))

This PR fixes these issues. Furthermore, a new method coloring_maps is added to calculate the group homomorphisms explicitly. This can also be used to verify the results of the method colorings. Finally, the plot method is adapted to the changes.

Note that the definition does not restrict n to be a prime number. However, if this is not the case, we cannot just take the next prime number to work more comfortably over a field. It is still necessary to work over the residue class ring modulo n. Although the method right_kernel_matrix works well in this context the method right_kernel does not work due to a failure in the span method of the FreeModule class. Since I didn't find an easy fix for this I worked around this issue.

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit e3f62be; changes) is ready! 🎉

[soehms]

Bot failures in the test log and also in this one are not related to the changes here!

[miguelmarco]

I would add the same comment as before:

 - ``n`` -- the number of colors to consider (if ommitted the
          value of the determinant of ``self`` will be taken

[soehms]

Thanks! I've done it in the current commit.

[miguelmarco]

Is there a reason to try to use nullity instead of going directly for the way that always works?

[soehms]

My intention is to maintain performance on prime numbers. It would decrease by a factor of 28:

sage: KnotInfo.K12a_1007.inject()
Defining K12a_1007
sage: K12a_1007.determinant()
143
sage: K = K12a_1007.link()
sage: M = K._coloring_matrix(n=13)
sage: %timeit M.nullity()
1.47 µs ± 169 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)
sage: %timeit M.right_kernel_matrix().dimensions()[0]
41.5 µs ± 1.09 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

For just one call this is negligible. But if invoked inside a large loop this could count.

[miguelmarco]

In that case, maybe checking for the ring to be a field would be better than trying and catching the exception.

[soehms]

In that case, maybe checking for the ring to be a field would be better than trying and catching the exception.

I agree! I just made the change.

[miguelmarco]

Automated tests were cancelled for some reason. Did you test it all?

[soehms]

Automated tests were cancelled for some reason. Did you test it all?

Only below src/sage/knots. I can do a complete run later on.

[miguelmarco]

If a full check is successful, it is ok from my part.

[soehms]

If a full check is successful, it is ok from my part.

I also had problems with doctests on my fastest machine (an import error on libflint). So, I had to rebuild from distclean to get it fixed.

In the meantime there is a successful bot test result triggered by synchronizing with 10.2.beta7.