train-tracks

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

We propose to implement in Sage the train-tracks package developed by Thierry Coulbois:

The main feature and the main achievement of the program is to compute train-track representative for (outer) automorphisms of free groups. phi.train track() computes a train-track representative for the (outer) automorphism phi. This train-track can be either an absolute train-track or a relative train-track. The celebrated theorem of Bestvina and Feighn assures that if phi is fully irreducible (iwip), then there exists an absolute train-track representing phi. The train-track(relative=False) method will terminate with either an absolute train-track or with a topological representative with a reduction: an invariant strict subgraph with non-trivial fundamental group. One more feature of train-tracks (absolute or relative) is to lower the number of Nielsen paths. Setting the stable=True option will return a train-track with at most one indivisible Nielsen path (per exponential stratum if it is a relative train-track).

See also:

• https://github.com/coulbois/sage-train-track
• https://www.i2m.univ-amu.fr/perso/thierry.coulbois/train-track/

• 31223: Add sage-train-track as an optional package

CC: @tscrim @sagetrac-tmonteil @videlec

Component: group theory

Keywords: free-group automorphism

Author: Dominique Benielli, Thierry Coulbois

Branch/Commit: public/train-track @ dcc540c

Issue created by migration from https://trac.sagemath.org/ticket/20154

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Changed keywords from none to free-group automorphisme

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Author: Dominique Benielli and Thierry Coulbois

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Description changed:

--- 
+++ 
@@ -1 +1,5 @@
+We propose to implement in Sage the train-tracks package developped by Thierry Coulbois:

+The main feature and the main achievement of the program is to compute train- track representative for (outer) automorphisms of free groups. phi.train track() computes a train-track representative for the (outer) automorphism phi. This train-track can be either an absolute train-track or a relative train-track. The celebrated theorem of Bestvina and Feighn [?] assures that if phi is fully irre- ducible (iwip) then there exists an absolute train-track representing phi.
+The train-track(relative=False) method will terminate with either an absolute train-track or with a topological representative with a reduction: an invariant strict subgraph with non-trivial fundamental group.
+One more feature of train-tracks (absolute or relative) is to lower the number of Nielsn paths. Setting the stable=True option will return a train-track with at most one indivisible Nielsen path (per exponential stratum if it is a relative train-track).

[tscrim]

Changed keywords from free-group automorphisme to free-group automorphism

[tscrim]

comment:2

Let me know if you have any questions or if there is anything I can do to help.

In case you were unaware, you might also be interested in that Sage has an implementation of right-angled Artin groups.

[tscrim]

Description changed:

--- 
+++ 
@@ -1,5 +1,10 @@
-We propose to implement in Sage the train-tracks package developped by Thierry Coulbois:
+We propose to implement in Sage the train-tracks package developed by Thierry Coulbois:

-The main feature and the main achievement of the program is to compute train- track representative for (outer) automorphisms of free groups. phi.train track() computes a train-track representative for the (outer) automorphism phi. This train-track can be either an absolute train-track or a relative train-track. The celebrated theorem of Bestvina and Feighn [?] assures that if phi is fully irre- ducible (iwip) then there exists an absolute train-track representing phi.
+The main feature and the main achievement of the program is to compute train-track representative for (outer) automorphisms of free groups. phi.train track() computes a train-track representative for the (outer) automorphism phi. This train-track can be either an absolute train-track or a relative train-track. The celebrated theorem of Bestvina and Feighn assures that if phi is fully irreducible (iwip), then there exists an absolute train-track representing phi.
 The train-track(relative=False) method will terminate with either an absolute train-track or with a topological representative with a reduction: an invariant strict subgraph with non-trivial fundamental group.
-One more feature of train-tracks (absolute or relative) is to lower the number of Nielsn paths. Setting the stable=True option will return a train-track with at most one indivisible Nielsen path (per exponential stratum if it is a relative train-track).
+One more feature of train-tracks (absolute or relative) is to lower the number of Nielsen paths. Setting the stable=True option will return a train-track with at most one indivisible Nielsen path (per exponential stratum if it is a relative train-track).
+
+See also:
+
+- https://github.com/coulbois/sage-train-track
+- https://www.i2m.univ-amu.fr/~coulbois/train-track/

[miguelmarco]

comment:4

I could be interested in this. Specially to add it as a functionality for Braid groups.

I have taken a quick look at Coulbois code, and it seems that it was writen before we had free groups in sage (or at least, he writes his own implementation of free groups).

So my impression is that we would need to heavily adapt his code in order to fit our current infrastructure.

If you are ok with it, we can start discussing which should be the right structure to follow.

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

comment:5

Replying to @miguelmarco:

I could be interested in this. Specially to add it as a functionality for Braid groups.

I have taken a quick look at Coulbois code, and it seems that it was writen before we had free groups in sage (or at least, he writes his own implementation of free groups).

So my impression is that we would need to heavily adapt his code in order to fit our current infrastructure.

If you are ok with it, we can start discussing which should be the right structure to follow.

Hi,

Thanks for your comment. We are still working on train-track adaptation for sage, format code, checked test , that takes more time that I expected were I opened the ticket ... Indeed our main issue is the FreeGroup implementation (we have already do some change comparing to the train-track code of Thierry) but we have still a reduced FreeGroup, and the compatibility with the FreeGroup is Sage is not easy (same use functionality). We of course ok to start discussing about this issue and we wish to find a light solution. The easiest way would be to rename our FreeGroup but may be we can make something better. So we are open to any suggestion. Dominique

[miguelmarco]

comment:6

Would it be possible to use sage's FreeGroup (maybe adding to it the functinalities that you need?)

[tscrim]

comment:7

Let me change the question slightly, what functionality from a free group do you need? (Also, you won't need to rename your free group because it is in a separate module.)

[d53c3c1f-61cc-4040-be1f-8ec5f87eb3a8]

comment:8

Hello the Sage community,

I finally got a trac.sagemath account to reply !

Of course we need to use (and adapt) the existing FreeGroup in Sage.

The main difference is my use of alphabets with inverse letters (AlphabetWithInverses in my program). There have been some discussions with Vincent Delecroix on my choices. I hope my code is not too poorly written and I can adapt easily.

The point is that my free groups are to be used as domain of WordMorphisms and as such they should have alphabets (and not only generators)... The elements should be words.

May be we could discuss that by mail with Vincent, Thierry M. and Marco ?

[edd8e884-f507-429a-b577-5d554626c0fe]

comment:9

Replying to @sagetrac-coulbois:

May be we could discuss that by mail with Vincent, Thierry M. and Marco ?

I think this thread/ticket is a good place as it allows other interested people to follow and join the discussion (and does not perturb others).

[miguelmarco]

comment:10

I also would prefear the discussion to happen here. But if it becomes useful at some point, we could try some kind of live meeting (via google hangouts or other similar means)

I am still trying to understand your code to see how could it fit with the existing sage classes.

[tscrim]

comment:11

It is also entirely possible we will need to abstract out code from the current FreeGroup, IndexedFreeGroup, and your implementation (and from a quick look-over, that is probably what will happen).

[d53c3c1f-61cc-4040-be1f-8ec5f87eb3a8]

comment:12

Yes of course we can also adapt the existing FreeGroup to my code. For that I need to know how much it is used. In particular as it seems to be only a wrapper of GAP.

Apparently there are two different approaches:

1/ The present FreeGroup (from GAP) focuses on the fact that free groups are algebraic objects (they have generators and the elements are somehow abstract group elements)

2/ Whereas my approach is closer to that of Words: free group are combinatorial objects and their elements are words on an alphabet.

I don't know how much these two approaches are compatible. And how much we can merge or converge to a common approach. The differences are probably similar to that between FreeMonoid and Words.

Marco can you tell us how much your FreeGroup is used, how much it is important that its elements are from a GAP wrap class (ElementLibGAP) ?

[tscrim]

comment:13

I have to run now, but a quick response. IIRC, it is used to construct the free algebra, but I believe you're right in that it is basically a wrapper of GAP. I'd have to double-check the latter.

[miguelmarco]

comment:14

Sage's FreeGroup implementation is mostly a wrapper around GAP's. I think we should keep that since it is the basis for FinitelyPresentedGroups, and BraidGroup's which are also wrapped around GAP.

Elements of a FreeGroup are represented internally as a Tietze list, so it should be easy to translate from that representation to the one based in words and back (as long as the names of the generators is kept clear). So, instead of rewriting the implementation, I would vote for implementing that translation (which could be interesting in itself), and use that to call your code.

[miguelmarco]

comment:15

By the way, I got an error when trying to test your code:

sage: from all import *
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-9796be731807> in <module>()
----> 1 from all import *

/home/mmarco/sage-train-track/all.py in <module>()
----> 1 from free_group import FreeGroup
      2 from free_group_automorphism import FreeGroupMorphism, FreeGroupAutomorphism, free_group_automorphisms
      3 from inverse_alphabet import AlphabetWithInverses

/home/mmarco/sage-train-track/free_group.py in <module>()
     13     from sage.combinat.words.words import FiniteWords_over_OrderedAlphabet as FiniteWords
     14 
---> 15 from inverse_alphabet import AlphabetWithInverses, AbstractAlphabetWithInverses
     16 from free_group_word import FreeGroupWord
     17 

ImportError: cannot import name AbstractAlphabetWithInverses

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Branch: u/dbenielli/train_tracks

[miguelmarco]

Commit: 8e7f630

[miguelmarco]

comment:17

Did you run the testsuite in this branch?

---

New commits:

8e7f630

first v of train track

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

comment:18

Yes, all tests passed

sage: from sage.combinat.words.all import * sage: AlphabetWithInverses(2) Alphabet with inverses on ['a', 'b']

[jhpalmieri]

comment:19

This is in response to http://ask.sagemath.org/question/33238/unable-to-build-the-doc-reference-html/. There are a lot of problems with the formatting of the docstrings. Here are a few fixes as illustrations. See also http://www.sphinx-doc.org/en/stable/rest.html and http://docutils.sourceforge.net/rst.html for the basics of reStructuredText, and http://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-strings for Sage-specific instructions.

diff --git a/src/sage/combinat/words/convex_core.py b/src/sage/combinat/words/convex_core.py
index 0183e0f..a3c873a 100644
--- a/src/sage/combinat/words/convex_core.py
+++ b/src/sage/combinat/words/convex_core.py
@@ -6,8 +6,8 @@ AUTHORS:

 - Thierry COULBOIS (2013-01-01) : initial version
 - Dominique BENIELLI (2016-02_15) :
-AMU University <dominique.benielli@univ-amu.fr>,
-Integration in SageMath
+  AMU University <dominique.benielli@univ-amu.fr>,
+  Integration in SageMath

 EXAMPLES::

@@ -46,13 +46,15 @@ class ConvexCore():
     Guirardel's convex core of two simplicial
     trees with an action of a free group.

-    Let T1 and T2 be trees with actions of the free group FN. G1=T1/FN
-    and G2=T2/FN are MarkedGraph.
+    Let `T_1` and `T_`2` be trees with actions of the free group `FN`. `G_1=T_1/FN`
+    and `G_2=T_2/FN` are MarkedGraph.

     A ConvexCore is a CW-complex of dimension 2. 2-cells are
     squares. 1-cells are edges labeled by edges of G1 or G2. A square
     is of the form

+    ::
+
           e
         ----->
        |      |
@@ -89,20 +91,20 @@ class ConvexCore():

     EXAMPLES::

-    sage: phi=FreeGroupAutomorphism("a->ab,b->ac,c->a")
-    sage: phi=phi*phi
-    sage: C=ConvexCore(phi)
-    sage: print C.slice('c',0)
-    Looped multi-digraph on 2 vertices
+        sage: phi=FreeGroupAutomorphism("a->ab,b->ac,c->a")
+        sage: phi=phi*phi
+        sage: C=ConvexCore(phi)
+        sage: print C.slice('c',0)
+        Looped multi-digraph on 2 vertices

-    sage: C.vertices()
-    [0, 1, 2, 3]
+        sage: C.vertices()
+        [0, 1, 2, 3]

-    sage: C.squares()
-    [[3, 0, 2, 1, 'c', 'a']]
+        sage: C.squares()
+        [[3, 0, 2, 1, 'c', 'a']]

-    sage: C.twice_light_squares()
-    [[1, 4, 0, 5, 'a', 'c']]
+        sage: C.twice_light_squares()
+        [[1, 4, 0, 5, 'a', 'c']]

     AUTHORS:

@@ -686,7 +688,7 @@ class ConvexCore():
         - a homotopy equivalence

         - that maps the root v0 of ``G0.spanning_tree()`` to the root v1 of
-        ``G1.spanning_tree()``
+          ``G1.spanning_tree()``

         - the image of each vertex has at least two gates.

@@ -771,27 +773,27 @@ class ConvexCore():

         - The boundary of a square is a list [e0,e1,e2,e3] of edges such that
-        e0=(w,v,(a,0)) and e2 are edges with a positive letter
-        a, and e1=(w,v,(b,1)) and e3 are edges with b a
-        positive letter.
+          e0=(w,v,(a,0)) and e2 are edges with a positive letter
+          a, and e1=(w,v,(b,1)) and e3 are edges with b a
+          positive letter.

         - The boundary of an edge it is the list [v0,v1] of the initial vertex
-        v0=(w,v) followed by the terminal vertex.
+          v0=(w,v) followed by the terminal vertex.

         Whereas for lists:

         - squares: ``[v0,v1,v2,v3,a,b]`` where v0,v1,v2 and v3 are
           integers standing for vertices and a,b are positive letters
-          labeling edges of G0 and G1:
+          labeling edges of G0 and G1::

                 a
-          v3 ------> v2
-           ^         ^
-           |         |
-           |b        |b
-           |         |
-           |    a    |
-          v0 ------>v1
+           v3 ------> v2
+            ^         ^
+            |         |
+            |b        |b
+            |         |
+            |    a    |
+           v0 ------>v1

         - edges: ``[v0,v1,(a,side)]`` where ``v0`` and ``v1`` are
           integers standing for vertices a is a label of the tree on
@@ -799,30 +801,30 @@ class ConvexCore():

         INPUT:

-        -``cell``square, an edge or a vertex. Squares are bounded
-        by four vertices, edges by two vertices.
+        - ``cell`` square, an edge or a vertex. Squares are bounded
+          by four vertices, edges by two vertices.

         OUTPUT:
         The boundary of a cell is the list of vertices bounding it.

         EXAMPLES::

-        sage: phi = FreeGroupAutomorphism("a->ab,b->ac,c->a")**2
-        sage: C = ConvexCore(phi)
-        sage: C.boundary((Word('C'), 0, 'c', 'a')) # boundary of a square
-        [(word: C, 0, ('c', 0)),
-        (word: , 0, ('a', 1)),
-        (word: Bc, 0, ('C', 0)),
-        (word: B, 0, ('A', 1))]
+            sage: phi = FreeGroupAutomorphism("a->ab,b->ac,c->a")**2
+            sage: C = ConvexCore(phi)
+            sage: C.boundary((Word('C'), 0, 'c', 'a')) # boundary of a square
+            [(word: C, 0, ('c', 0)),
+            (word: , 0, ('a', 1)),
+            (word: Bc, 0, ('C', 0)),
+            (word: B, 0, ('A', 1))]

-        sage: C.boundary([3, 0, 2, 1, 'c', 'a']) # boundary of a square
-        [[3, 0, ('c', 0)], [0, 2, ('a', 1)], [2, 1, ('C', 0)], [1, 3, ('A', 1)]]
+            sage: C.boundary([3, 0, 2, 1, 'c', 'a']) # boundary of a square
+            [[3, 0, ('c', 0)], [0, 2, ('a', 1)], [2, 1, ('C', 0)], [1, 3, ('A', 1)]]

-        sage: C.boundary((Word('Bc'),0,('C',0))) # boundary of an edge 
-        [(word: Bc, 0), (word: B, 0)]
+            sage: C.boundary((Word('Bc'),0,('C',0))) # boundary of an edge 
+            [(word: Bc, 0), (word: B, 0)]

-        sage: C.boundary([2,1,'C']) # boundary of an edge
-        [2, 1]
+            sage: C.boundary([2,1,'C']) # boundary of an edge
+            [2, 1]
         """

         if isinstance(cell, tuple):

[miguelmarco]

comment:20

Building documentation fails. And I get many doctest failing:

sage -t --warn-long 47.3 src/sage/combinat/words/test_train_track.py # 5 doctests failed sage -t --warn-long 47.3 src/sage/misc/sagedoc.py # 4 doctests failed sage -t --warn-long 47.3 src/sage/categories/groups.py # 2 doctests failed sage -t --warn-long 47.3 src/sage/categories/magmas.py # 13 doctests failed sage -t --warn-long 47.3 src/sage/modules/vector_double_dense.pyx # 1 doctest failed sage -t --warn-long 47.3 src/sage/modules/with_basis/representation.py # 2 doctests failed sage -t --warn-long 47.3 src/sage/groups/braid.py # 27 doctests failed sage -t --warn-long 47.3 src/sage/groups/libgap_wrapper.pyx # 76 doctests failed sage -t --warn-long 47.3 src/sage/groups/finitely_presented.py # 241 doctests failed sage -t --warn-long 47.3 src/sage/groups/group.pyx # 2 doctests failed sage -t --warn-long 47.3 src/sage/groups/free_group.py # 123 doctests failed sage -t --warn-long 47.3 src/sage/groups/libgap_group.py # 11 doctests failed sage -t --warn-long 47.3 src/sage/groups/generic.py # 3 doctests failed

I don't think it is a good idea to override the default FreeGorup implementation. Many parts of Sage deppend on it. It would make more sense to extend it with the methods that are needed for the rest of your code.

[fchapoton]

Changed author from Dominique Benielli and Thierry Coulbois to Dominique Benielli, Thierry Coulbois

[fchapoton]

comment:22

please use python3 style of print function everywhere : print(x)

[d53c3c1f-61cc-4040-be1f-8ec5f87eb3a8]

comment:23

Yes, I begin to understand, that I will need to use (and add functionalities) to the current FreeGroup.

The main difficulty is that I rely heavily on WordMorphism, in particular for parsing:

FreeGroupAutomorphism("a->ab,b->aC,c->a")

And for applying or compose morphisms. These are heavily used in my program.

This suggest that I would like that my elements of FreeGroup are Word. Do you have any objection to FreeGroup also inheriting from Words ? And FreeGroupElement from Word ?

I guess that it is not too complicated to add Words and Word methods to your FreeGroup and FreeGroupElement. But will that interfere with deeper GAP implementations (I am completly new to GAP)?

Would that be satisfactory to Sage gurus that FreeGroup are both an algebraic object and a symbolic one ?

Finally there is also a IndexedFreeGroup class which is not a wrapper of GAP, how does it fit in this discussion ?

I don't think it is a good idea to override the default FreeGorup implementation. Many parts of Sage deppend on it. It would make more sense to extend it with the methods that are needed for the rest of your code.

[miguelmarco]

comment:24

I guess it makes sense to consider FreeGroupElements as Words, but we should be careful to make sure that the multiple inheritance doesn't break anything. We should also probably rewrite the different constructors.

In any case, we need a class for morphisms of free groups (or more general, finitely presented groups), so it might be a good opportunity to design that infrastructure.

[tscrim]

comment:25

Replying to @miguelmarco:

In any case, we need a class for morphisms of free groups (or more general, finitely presented groups), so it might be a good opportunity to design that infrastructure.

This is my opinion as well. Parsing of the input is an API decision and, IMO, not a good reason to use a specific implementation. Unless you are using other features of WordMorphism that are not (currently) available to the current group morphisms or I am misunderstanding comment:23.

Actually, I am somewhat not in favor of using words because of the need to handle inverses in the free group. There should not really be that much of an implementation difference between the free group using words or GAP, just an API difference...at least I'd imagine there shouldn't be...

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 8e7f630 to 2fbe7c6

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

2fbe7c6

improvment for doc build

[d53c3c1f-61cc-4040-be1f-8ec5f87eb3a8]

comment:27

Dominique finished to set-up the test and to clean-up the doc. Let's say that we have a clean version 1. I am refering to the master branch of my https://github.com/coulbois/sage-train-track repository.

1/ Please try and explore this version for functionnalities. Do you find all what you need for free group automorphisms and train-tracks ?

2/ Now, we need to make that compatible with the FreeGroup of sage.groups. I propose to start from the file sage.groups.free_group.py and add the methods I need. This is the purpose of the work branch in my https://github.com/coulbois/sage-train-track repository. I fear that this implies giving-up the fact that free groups elements are words. Everybody is okay with that ?

(I guess I am not in the correct Sage workflow, please comment if you have a better one).

[tscrim]

comment:28

I still haven't taken a detailed looked yet (sorry), but this does look very impressive. I am looking forward to getting this project and code included into Sage.

I think it would be good for you to list here exactly what functionality you're missing from free groups in Sage (and their morphisms) and/or to create a separate ticket, which would become a dependency of this ticket, that would implement these features.

Although, you are not really loosing the interpretation of free group elements as words because you have the Tietze(), but it will likely require some changes to the implementations. (Sorry for a bit of repetition, but IMO, a finite word is much more naturally associated with a free monoid because of the concatenation does not involve cancellation.) The biggest possible obstruction to this that I see currently is that you are using some feature only implemented for word morphisms.

Math question, does the theory of train-tracks extend to free groups on (countably) infinite generators?

[miguelmarco]

comment:29

2/ Now, we need to make that compatible with the FreeGroup of sage.groups. I propose to start from the file sage.groups.free_group.py and add the methods I need. This is the purpose of the work branch in my https://github.com/coulbois/sage-train-track repository. I fear that this implies giving-up the fact that free groups elements are words. Everybody is okay with that ?

I am certainly okay with that. From a quick look at your code, it sounds very natural to rewrite it on top of existing FreeGroups (for instance, you needed to add some way to concatenate word with cancelations, whereas in the framework of freegroups you have all that for free as the standard product).

(I guess I am not in the correct Sage workflow, please comment if you have a better one).

In theory, we should handle the branches in this server instead of github. But given the size of the project, and the fact that we are in a stage where we are pretty much experimenting before deciding the actual dessign, it may be ok to handle this early branches somewhere else (as long is everybody is ok about working through github). Although at some point we should move it all to trac branches.

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

comment:30

Hi all,

As Thierry says previously we decided to make the compatibilyty with the sage FreeGroup through the hard way, used it and add functionnalities. Three or more module need to be rewrited, when we obtain a first draft version I am pushing in in the sage ticket. So there no need for you to worry about a external branche.

Dominique

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 2fbe7c6 to 3ecdcdf

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

3ecdcdf

rm fille

[d53c3c1f-61cc-4040-be1f-8ec5f87eb3a8]

comment:32

Advice/approval needed

I started using and modifying the existing FreeGroup. I refer to the work branch of my git repo (not the sage one)

1/ My guess is that I can rely mainly on the Tietze() method of FreeGroupElement. I have no idea of the GAP implementation of FreeGroupElement.

2/ I extended init() methods to allow more API (accepting strings for example). I added __getitem__ and comparisons methods. Now FreeGroupElement behave loosely as words and I expect to rely on them.

3/ I started to adapt the FreeGroupMorphism. I am not really willing to write a GroupMorphism (even an abstract one) class as I have no idea of what Group and GroupElement look like. I propose to use a _morph variable to store a dictionnary that map FreeGroupElement (the generators and their inverses) to FreeGroupElement (once again I have no idea of the cost, may be a dictionnary from integers to integer list together with Tietze() would be more efficient though less natural).

The doc is not yet up-to-date.

I am currently working further. But please stop me if you believe my choices are stupid.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

efa12d3

remove all

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 3ecdcdf to efa12d3

[tscrim]

comment:34

Replying to @sagetrac-coulbois:

1/ My guess is that I can rely mainly on the Tietze() method of FreeGroupElement. I have no idea of the GAP implementation of FreeGroupElement.

This is the way to go because Tietze() pull info from its GAP data. This should also be reasonably fast.

2/ I extended init() methods to allow more API (accepting strings for example). I added __getitem__ and comparisons methods. Now FreeGroupElement behave loosely as words and I expect to rely on them.

I am okay with the __getitem__. There is a default total order from the generic GAP element implementation, which the total order may or may not be good, but it is likely one of the faster ways to check for (in)equality. However, I haven't looked at your current code yet.

3/ I started to adapt the FreeGroupMorphism. I am not really willing to write a GroupMorphism (even an abstract one) class as I have no idea of what Group and GroupElement look like. I propose to use a _morph variable to store a dictionnary that map FreeGroupElement (the generators and their inverses) to FreeGroupElement (once again I have no idea of the cost, may be a dictionnary from integers to integer list together with Tietze() would be more efficient though less natural).

No matter what, I think you would need a FreeGroupMorphism class for everything that you want to do. I think the internal storage method should depend on the application, but the user input should be a tuple, which is consistent with the rest of Sage and requires less validation of the input.

You will probably want to create a FreeGroupHomset (which you will need to add a _hom_ method to FreeGroup to create this), whose elements are your FreeGroupMorphism, which can be constructed directly from the hom method. By having the morphism take a tuple as input, you shouldn't have to modify the hom method.

A question: does your framework handle morphisms to free groups with different generator labels? If not, would it be easy to support this (and do you want to)? If also no, then don't worry about it.

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Changed branch from u/dbenielli/train_tracks to public/train_track

[5e1794c3-77c0-453a-bf39-4b14c1cb833c]

Changed commit from efa12d3 to none

[videlec]

Commit: 9f9d12b

[videlec]

Changed branch from public/train_track to public/train-track

[videlec]

New commits:

dce1fc0	initial commit for train track for free groups
2f68ae6	print p3
8a67358	doc
80381b4	doc
0e2401f	tests passed
02f8668	deprecation warning for the old free_group.py file
ea56cef	simpler comparisons
9f9d12b	remove trailing whitespaces

[videlec]

comment:38

(I fixed the name of the branch, it was train-track and not train_track)

[fchapoton]

comment:39

For python3 compatibility:

• please do not use the it.next method, but instead next(it)

• please do not write print (something) but rather print(something) (no space after print)

see my patchbot's report for more information

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 9f9d12b to 020d0a2

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

020d0a2

python3 compatibility