Fix MIP Infeasibility/Unbounded errors and incorrect distance results by updating project.toml compat

[Fe-r-oz]

Both HiGHS, and Gurobi yield INFEASIBLE or UNBOUNDED errors if they are unable to find the solution to integer programming problem for code computation. This is resolved by removing the erroneous examples where this occurs, and specifically computing dx, dz. The project.toml is updated to the latest version as well.

• The code is properly formatted and commented.
• Substantial new functionality is documented within the docs.
• All new functionality is tested.
• All of the automated tests on github pass.
• We recently started enforcing formatting checks. If formatting issues are reported in the new code you have written, please correct them.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.15%. Comparing base (983a167) to head (64f4bdd).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #61      +/-   ##
==========================================
- Coverage   95.52%   95.15%   -0.38%     
==========================================
  Files           8        8              
  Lines         760      763       +3     
==========================================
  Hits          726      726              
- Misses         34       37       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Fe-r-oz]

There was some issues with compiling QuantumExpanders.jl on wsl locally -- so there is a bit of lag in requesting reviews of these PR -- will pick up speed soon

[Fe-r-oz]

Turning to draft to do some more work

[Fe-r-oz]

The following mermaid schematic is added to the ReadME:

graph TD
    QuantumTannerCodes["Quantum Tanner Codes"] --> RandomMethods["Random Methods"]
    QuantumTannerCodes --> DeterministicMethods["Deterministic Methods"]

    subgraph "Random construction"
        RandomMethods --> RandomQuantumTannerCode["`random_quantum_Tanner_code`"]
    end

    subgraph "Deterministic construction"
        DeterministicMethods --> QuantumTannerCode["`QuantumTannerCode`"]
        DeterministicMethods --> GeneralizedQuantumTannerCode["`GeneralizedQuantumTannerCode`"]
    end

Loading

[Fe-r-oz]

@Krastanov, the PR is ready for review. I encountered some issues setting up the library locally due to computer problems, which caused a few mistakes and led to a slight delay in closely investigating everything

[Fe-r-oz]

Just to clarify, I meant that some non-functional updates such as compact rounds and documentation were not yet finalized, and there are no issues with correctness of the methods since they are tested

[Krastanov]

If this example involves a random search, it will break again in six months when something else in the Random.jl internals changes.

[Fe-r-oz]

The example is fully deterministic. The random search is over input paramters, like what classical code pairs are best, but the code instance itself is fully reproducible.

"""
Here is new [[36, 8, (3,3)]] code found via random search:

julia> F = free_group([:s, :r]);

julia> s, r = gens(F);

julia> rels = [s^2, r^4, s*r*s*r];

julia> G, epimorphism = quo(F, rels);

julia> s, r = epimorphism(s), epimorphism(r);

julia> A = [s, r, r^3];

julia> B = [s*r, s*r^3, r^2];

julia> H_A = [1  0  1; 0  1  1];

julia> G_A = [1  1  1];

julia> H_B = [1  1  1];

julia> G_B = [1  1  0; 1  0  1];

julia> classical_code_pair = ((H_A, G_A), (H_B, G_B));

julia> c = QuantumTannerCode(G, A, B, classical_code_pair);

julia> import JuMP; import HiGHS;

julia> code_n(c), code_k(c), distance(c, DistanceMIPAlgorithm(solver=HiGHS))
(36, 8, 3)

"""

[Krastanov]

This is a pretty weird change, a very good example of some of the weird changes in this PR.

You seem to have changed many of the broken tests with new similar but not the same tests (that now pass). But the broken tests were not actually fixed, they were replaced.

Given the state of the library, this is probably the best way forward and I have no qualms with it. But for the sake of documentation, could you explain why you have made these changes (in comments here). In particular, were the old broken tests wrong? Or were they in a format that was just difficult to reproduce? Are the new tests more "canonical" in some way, or are they also just some arbitrary tests? Why should be expect the new tests to not break in the future given that the old tests broke? Basically, I have the impression that you deleted some example codes and added new different example codes, and it feels kinda arbitrary.

Please try to be brief in your answer. Feel free to just answer whatever you perceive as the most important question above, not to answer them one-by-one. I am looking for a simple reason to trust all these numerous minute changes -- if they were necessary, why are you sure similar changes will not be needed in another year.

[Fe-r-oz]

The “broken” tests were not incorrect implementation of QuantumTannerCode that causes the tests to broke, but examples of quantum Tanner codes whose true minimum distance is poor in one basis. After the compatibility-bound changes in QuantumClifford.jl, I retested the codes more systematically and started reporting the full minimum-distance ($d_X$, $d_Z$) instead of only $d_Z$.

In most cases, I did not replace the tests: they are the same codes as before, but with separate verification of $d_X$ and $d_Z$. For some tests, including the example you pointed out, I changed the parameters to use codes with more meaningful distances (for example, ([[360,8,10,3]])) rather than keeping examples with poor distance in both bases. My goal was to keep examples that are more representative of good codes (from Morgensterns generators) and useful for documentation and regression testing.

Since I have been building much of this library almost from scratch alongside developing new methods for searching quantum Tanner codes, many of the original test instances were exploratory examples generated during that process. At the time, I had not yet systematically validated both their X- and Z-basis minimum distances, whereas these tests now do.

After retesting the codes more carefully, I removed some whose true minimum distance turned out to be 1, since I do not think such examples are especially useful as regression tests. A smaller number of tests were also removed because the HiGHS/MIP minimum-distance computation occasionally returns unstable “INFEASIBLE/UNBOUNDED” behavior on those instances, making the tests unreliable.

[Krastanov]

Looks good to merge, but for dev-documentation purposes, please comment with a brief answer to the questions above.

[Fe-r-oz]

Thank you, I have added brief comments addressing the questions above. Please me know if anything else should be clarified