The Fusion Ring of the Drinfeld Double of a Finite Group

[dwbump]

📚 Description

This code is very similar to the existing FusionRing class. Both FusionRing and the new FusionDouble classes implement Fusion Rings of Modular Tensor Categories, important in conformal field theory and related quantum math. The FusionDouble is the fusion ring of the Drinfeld double of a finite group. It has methods corresponding to fusion, S-matrix, twists of simple elements, quantum dimension. An interface is provide to the F-matrix code, but due to the fact that the number of simple objects is fairly large even for fairly small groups, the F-matrix code is only confirmed to work for very small group such as Z_2 and S_3. Apart from the F-matrix code, the code works for Drinfeld doubles of moderate size, tested for example on groups of order 16, and the simple groups A5 and GL(3,2) of orders 60 and 168.

A prototype of this code by Wenqi Li is here: https://github.com/enqiLi/drinfeld_doubles

Work issues:

*The code would benefit from refactoring with the existing FusionRing code. It is proposed that we skip this since the existing code works well.
*The Drinfeld double can be twisted by a 3-cocycle for H^3(G). This may be implemented in a later PR.

📝 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

[fchapoton]

One linter (see checks) is not happy about some import and about not using EXAMPLES:: (note the plural)

[fchapoton]

and the pycodestyle linter complains too

[fchapoton]

pycodestyle is not yet satisfied ; look at any other file in sage to see how the files must finish

[dwbump]

The codecov/project reported coverage failures are mostly related to the base correlation. When the F-matrix is calculated, the FusionDouble acquires an attribute called _basecoer, which is a coercion into the fvars_field, which is the field containing the F-matrix values. If this attribute is not None, then for every calculation, such as a call to s_matrix, the output is coerced into the fvars_field. These coercions are not tested by the existing doctests. The same is true for the coercions in fusion_ring.py.

[tscrim]

I wouldn't worry about the codecov stuff. I find it highly annoying/intrusive and would love to apply fire and holy water to it.

[dwbump]

Strange, that test was passing for me on my Ubuntu machine. What was the output you were getting?

Although I think it is better to have the call to FusionDouble error out as the doctest as it more clearly demonstrates that > it does not work. Say, if we re-implement this later without needed the centralizer() call, then we won't have any doctest > failure indication that we need to change something in the doc(tests).

I had two failures on both my two linux boxes, and also the bot was unhappy.

The output was similar to MacOS. The backtrace begins with a KeyError, in both cases. I spent some time trying to figure out what was going on, gave up, and just took the test out. It seems to me that the purpose of the discussion in the docstring is to tell the user how to proceed.

[tscrim]

It isn't just telling the user how to proceed, but to also have something in place to indicate when the documentation might become out of date.

For instance, it seems to be easy enough to implement a centralizer method for matrix groups:

sage: G = groups.matrix.GL(2,3)
sage: C = G._libgap_().Centralizer(G.random_element()); C
<group of 2x2 matrices over GF(3)>
sage: G.subgroup([matrix(M.sage()) for M in C.List()])
Subgroup with 4 generators (
[1 0]  [0 1]  [2 0]  [0 2]
[0 1], [1 0], [0 2], [2 0]
) of General Linear Group of degree 2 over Finite Field of size 3

(with some care for making sure the group is finite). GAP supports it some level of generality too: https://docs.gap-system.org/doc/ref/chap35.html#X7A2BF4527E08803C So with such a PR, I might fix the failure for matrix groups.

The fact that you are getting a very different failure is also concerning. Are you running the latest beta version? Can you post what the error message is? (I don't know how to see the old bot report.)

[tscrim]

Implementing the centralizers is now #35540.

[tscrim]

With #35540 , I can now construct the FusionDouble for GL(2, 3).

[dwbump]

With #35540 , I can now construct the FusionDouble for GL(2, 3).

Then perhaps we should take the discussion of the example at fusion_double.py:132.
Simply removing it would be acceptable whether or not this PR goes in before or after #35540.

[tscrim]

That's fine with me. We can potentially add it back in during the refactor PR #35540 is not done approved

[tscrim]

Thank you. LGTM. Anything further we can do on the refactoring ticket.

[mkoeppe]

I'd suggest to break long output lines like this one so that the example can be read in the HTML documentation without need for horizontal scrolling

[dwbump]

I'd suggest to break long output lines like this one so that the example can be read in the HTML documentation without need for horizontal scrolling

OK, I did this in commit c9c532d.

[mkoeppe]

pycodestyle complains about trailing whitespace

[mkoeppe]

Thank you, looking good.

[github-actions]

Documentation preview for this PR is ready! 🎉
Built with commit: 7fa61e4