Retrieve more information of fundamental groups of plane curves

[enriqueartal]

The goal of this PR is to add some features to the computation of fundamental groups of complements of the plane curves introduced in Sagemath by @miguelmarco and his optional package sirocco. It also corrects a bug introduced in #35376 and cleans some code.

We add the following information: given a tuple of curves we retrieve the information of meridians of each curve as words in the fundamental group, and also of the strands of the braid monodromy. We also add the possibility of excluding the vertical lines from the computation of braid monodromy (as far as there is no vertical asymptote) which makes its computation faster.

To achieve this goal we introduce new classes AffinePlaneCurveArrangements and ProjectivePlaneCurveArrangements. For now, they serve only to compute the fundamental groups with the meridian information (and braid monodromy and strand information for the affine curves) but more methods may be constructed in the future. The structure of these classes follows the one of HyperplaneArrangements, with one difference, the order is important. This is why we also introduce the class of OrderedHyperplaneArrangements, where the fundamental group is computed. We have also introduce a new method for hyperplane arrangements, jhyperplane_section, in order to compute the fundamental group also for hyperplane arrangements and not only for line arrangements.

These are the main changes:

• schemes/curves/affine_curve.py
  • Introducion of some auxiliary new methods: has_vertical_asymptote, is_vertical_line
  • Small update of fundamental_group
• schemes/curves/projective_curve.py. Some trivial cases were not considered in fundamental_group.
• schemes/curves/plane_curve_arrangement.py. New file with the new classes.
• schemes/curves/zariski_vankampen.py
  • For consistency some lists are converted into tuples.
  • Some functions take a new keyword to take into account the option of eliminating the vertical lines for the computation of the braid monodromy.
  • In braid_in_segment, correction of the bug introduced in the previous PR (the parameters must be in the number field embedded in QQbar).
  • The function geometric_basis has been changed for designed and to cover some cases where the former one failed.
  • A new function vertical_lines_in_braidmon to isolate vertical lines if needed.
  • The function braid_monodromy has been cleaned and now it takes into account the strand information.
• geometry/hyperplane_arrangement/arrangement.py
  • Introducion of the class of OrderedHyperplaneArrangements. The hyperplanes are not sorted in this class and the introduction order is respected. It forces to update some methods.
  • Five new methods for this new class: hyperplane_section, affine_fundamental_group, affine_meridians, projective_fundamental_group, and projective_meridians.

📝 Checklist

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

[vbraun]

merge conflict

[enriqueartal]

@vbraun: Commit enriqueartal@8bb020e solves the merge conflict but I am not sure if it is in the correct way.

[enriqueartal]

@tscrim @miguelmarco I repaired the merge conflicts due to the addition of new classes and the changes in all.py files but I would prefer someone more experienced checks the changes in order to avoid more conflicts.

[tscrim]

Almost okay. You need to remove the (lazy) imports from all__sagemath_polyhedra.py (now the all.py files seem to have been split and made significantly more complicated…).

[enriqueartal]

I did not touch all__sagemath_polyhedra.py; is it enough to put there the class OrderedHyperplaneArrangements and remove the new all_py in hyperplane_arrangement? Since I do not understand this change, I wonder how sirocco is affected.

[enriqueartal]

Finally I simplified all.py in the folder hyperplane_arrangement and I added the new class in all__sagemath_polyhedra.py
If you find it right I may take out the 🏷️s: needs work

[tscrim]

This is probably “better,” thanks.

[vbraun]

merge conflict

[enriqueartal]

@vbraun I reverted the all.py with new classes to try to avoid conflicts.

[tscrim]

@enriqueartal Do you think it would be possible (and reasonable) to squash at least the commits down? It would help keep the history a bit more clean for future debugging purposes. It's okay to leave it be if it's too much trouble.

[enriqueartal]

@enriqueartal Do you think it would be possible (and reasonable) to squash at least the commits down? It would help keep the history a bit more clean for future debugging purposes. It's okay to leave it be if it's too much trouble.

I agree with you, 148 are too much and plenty of them are only typos. What would be the best way?

[tscrim]

I would first do a rebase on develop (this should get rid of any merge commit) and then an interactive rebase to squash some of the commits down. Although the first step might be annoying having to deal with conflicts (again).

[enriqueartal]

I will try tomorrow with some help

[enriqueartal]

This week is quite complicated and I am afraid to do not squash the commits correctly.

[tscrim]

You can push a copy of this branch as a backup (and use as a comparison with git diff). As long as you end up with the same diff, then everything else will be okay.