Changes to accomodate new data

[borisdevos]

• The parsing functions needed to read different regex strings, but since we keep some of our old data there's some if-elses to deal with those.
• Right now I permuted the F-symbol indices that doesn't do anything yet, but at some point I wish to rearrange our old data such that the indices are in a much more natural order. This is mostly for if we wish to read in more multiplicity-full data where we don't have to do unusual permutations there.
• Since we keep our own Haagerup data, I had to separate this from the one gotten from anyonwiki.
• I commented out the aliases for two reasons. On the one hand, it's easier to figure out the category you want now that it follows the anyonwiki notation strictly. On the other hand, it's annoying to one-to-one find which pentagon and hexagon labels precisely target the aliases we had. It's certainly possible, but I didn't want to do it 🫠

I know with this that the identification PRs of Chenqi have to be looked at again, but it should in principle be easier this time around.

Should probably first merge #35 so the new data get tested properly.

[lkdvos]

Overall looks very reasonable, but there a few comments. (For convenience, let me review both this and #50 together):

In the data branch, there is a small readme file that documents the conventions of the data files. I don't care too much which format you choose, but I have to say that storing files in different orders based on whether the separator is '\t' or ' ' is seems like a recipe for disaster. Is there a way you could just pre-process all of the files into the same format?

It seems like the new data has significantly more digits than what we had before. Is this ever really useful? This might just make the files bigger with little gain, since we still read everything as Float64 anyways.

You will definitely have to increase the version, since this should count as a breaking change.

You could consider releasing a temporary version of the data from your branch, and then linking to it here. (These can be removed again so no worries about having to redo this a couple times). This way, we can start testing everything is still working as expected

[lkdvos]

Just for my own sanity, what is now the conventions you settled on? Why are there still the various cases in the parsing machinery?

[borisdevos]

All multiplicity-full cases + the two centers + some Haagerups which the anyonwiki doesn't have are untouched, so in particular their data follow the old convention. The new anyonwiki data are all multiplicity-free, so there's a bunch less columns in the data. The various parsing cases just separate these based on counting columns and fill in the missing ones in the multiplicity-free case.

[borisdevos]

Also I believe the tests are getting stuck somewhere, since it's hard to imagine the tests now taking almost 2 hours. There's also not much printing in the actions

[borisdevos]

For the parsing, the try - catch blocks were actually doing work and making sure to catch wrongly formatted data, also in case some values were not Ints and they should have been, etc... Is there a way to restore that behavior?

Just to be transparent on what's happening now, I added anchors to the regex strings so it will actually return nothing when the match isn't perfect structurally. This means that the parse calls will then return method errors from trying to do something on nothing.

[borisdevos]

Thanks to @VictorVanthilt and the windows terminal I can see that the categories which fail are PMFC{7, 1, 2, 11, x, y} for x=1,2 and y=1,2,3. Notably, PMFC{7,1,2,11,x,4} does pass the tests. They actually don't just fail at the artin braid, but at the hexagon equations. For now I'll ask Gert whether that's an error or if they're actually good on his side. Though I do think it's a good sign we have at least have one unitary solution to this particular category.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/CategoryData.jl	100.00% <ø> (ø)
src/artifacts.jl	91.69% <100.00%> (+2.76%)	⬆️
src/categories.jl	100.00% <100.00%> (ø)
src/prettyprinting.jl	69.76% <ø> (+7.76%)	⬆️

🚀 New features to boost your workflow:

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

[borisdevos]

Great, since tests are finally passing I can explain some of the changes I had to make. I'll summarise here even though I made some data changes as well.

It turns out that it was incorrect of me to store one set of F-symbols for the different R-symbols satisfying the hexagon equations. Apparently, there's some gauge freedom which will also change the F-symbols for fixed 'pentagon index' and varying 'hexagon index' in the anyonwiki, which was not the case with the old data. It was quite remarkable that this only raised an issue for the one particular fusion ring I mentioned above, but to be extra careful I have uploaded all the F-symbols now as well.

As a consequence, these F-symbol files now necessarily require a hexagon index. I've set the unbraided categories to have hexagon index 0, and the rest match the R-symbols which pair with these of the same hexagon index. I've changed some things in the source code to also keep track of this extra index, and to differentiate between braided and unbraided fusion categories. This way, we don't test braided categories twice, and users still need to explicitly defined unbraided fusion categories as unbraided through UFC.

It's still correct to not store the pivotal index, as there's only one of these for fixed pentagon and hexagon index which gives a unitary category. I've added a comment on this in the readme.

[borisdevos]

The one thing that's not being caught by the tests is the commented aliases not existing, so the grouplike pretty printing for D_N and S_N aren't working. @lkdvos since we're breaking things anyway, I'd like to just remove these, along with the CenterTable. It was always a bit odd to export variables called S, D, Z. Thoughts on this?

[lkdvos]

Considering the Fsymbol changes, I guess it is mostly up to you to evaluate how much of an issue this is, but to me that sounds like a very unwanted property to have, as the structure of our types etc really does reflect the idea that the "fusion category" part of equal pentagon indices are the same. Can we contact Gert and just gauge the Rsymbols correctly?

For the aliases, the main point was not about the pretty-printing, but rather the discoverability of the categories. I'm not sure if this is now less of an issue with the matching with the Anyon wiki, but that would be my main concern.

Otherwise, the main thing that looks still a bit off to me is the combination of the data formats where you just try to parse one and then the other still looks a little silly, and I would advise to stick to one for uniformity and future maintainability, but if it works right now this is also not a hill I will die on.

[borisdevos]

Considering the Fsymbol changes, I guess it is mostly up to you to evaluate how much of an issue this is, but to me that sounds like a very unwanted property to have, as the structure of our types etc really does reflect the idea that the "fusion category" part of equal pentagon indices are the same. Can we contact Gert and just gauge the Rsymbols correctly?

At least for me, the goal was to be as loyal to the anyonwiki's data as possible, so the only manipulation I've done is to truncate the data since we just work with double precision. I can certainly ask Gert if he has plans to do this gauging, but if it's just for us, then I'd prefer to be as literally close to the anyonwiki as possible.

For the aliases, the main point was not about the pretty-printing, but rather the discoverability of the categories. I'm not sure if this is now less of an issue with the matching with the Anyon wiki, but that would be my main concern.

Similar to my point above, if our data follows the anyonwiki literally, then every category here is as discoverable as it is there. So I think it's fine to limit ourselves to aliases for our own data.

Otherwise, the main thing that looks still a bit off to me is the combination of the data formats where you just try to parse one and then the other still looks a little silly, and I would advise to stick to one for uniformity and future maintainability, but if it works right now this is also not a hill I will die on.

Again somewhat connected to above, I didn't want to manipulate the anyonwiki's data too much, so in particular I respected the multiplicity-free way of storing data. There's already so much data, so adding columns of 1s to all the anyonwiki files will just bloat it even more. But this isn't hard to do, so it's definitely possible! I think either way I will add the script I've been running to convert the anyonwiki data to the ones I've uploaded, so it's reproducible for others in the future, and should be helpful for maintainability.

[lkdvos]

Sounds all very reasonable to me!

For the data format, I indeed forgot about the multiplicity differences, my bad!
In that case, I would just say to make the regex patterns consts and give them both a name that reflects this, just so it's easier to follow what is going on, but otherwise I think this looks good to go?

[borisdevos]

Great! If things pass, then we can merge the PR to the data branch first so I can release that, and then make the artifact changes to this PR.