#20154: train-tracks
-------------------------------------+-------------------------------------
Reporter: dbenielli | Owner:
Type: task | Status: new
Priority: major | Milestone: sage-7.1
Component: combinatorics | Resolution:
Keywords: free-group | Merged in:
automorphism | Reviewers:
Authors: Dominique | Work issues:
Benielli, Thierry Coulbois | Commit:
Report Upstream: N/A | efa12d37913aadd10e7c8cb59e9068aae64e6ff7
Branch: | Stopgaps:
u/dbenielli/train_tracks |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:32 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.
--
Ticket URL: <http://trac.sagemath.org/ticket/20154#comment:34>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
