Add additional mutation options for clusters

[thecaligarmo]

Adding additional mutation options to ClusterSeed and ClusterQuiver. These options include:

• mutating by sources and sinks
• mutating by green and red vertices
• mutating by urban renewals

Additionally, we add a mutation analysis which goes through and returns basic properties of all mutations possible from the current state.

Update functionality to cluster seed in order to:

• Use c-vectors for faster calculations of mutations
• Update c, d and g vectors to use faster algorithms
• Add mutation tracking
• Allow relabelling of vertices in graphs
• Allow searching for green vertices

CC: @egunawan @Etn40ff

Component: combinatorics

Keywords: SageDays64.5, clusters, mutation, seeds, quiver

Author: Aram Dermenjian, Gregg Musiker

Branch/Commit: f257d82

Reviewer: Viviane Pons, Christian Stump

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

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

Changed commit from 124befa to 39f1543

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

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

9084d1d	Merge branch 'public/ticket/18594' into 6.9.b3
39f1543	trac #18594 fixing doc

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

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

4d90a7f

doc cleanup

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

Changed commit from 39f1543 to 4d90a7f

[stumpc5]

comment:38

If everyone agrees that the discussed problems with the stuff implemented here can and will be fixed within finite time, I will give this ticket a positive review in order to enable the SageDays participants to submit further work.

[stumpc5]

comment:39

I actually would also be in favour of adding a list of the raised issues concerning this tickets in order to have it written down for future references.

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

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

f257d82

changed import numpy commands

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

Changed commit from 4d90a7f to f257d82

[a9a57cdf-9183-46c4-a1f6-41c1b5271dce]

comment:41

For posterity, here is a list of concerns that were raised by Salvatore Stella and Christian Stump regarding the cluster_seed.py file.

These should be taken care of in a future ticket:

• There is a lot of duplicated information in the data structures for ClusterSeed. For example, the mutable part of the B matrix is stored at least in _M, _B, _BC, and as part of the data structure of _quiver. Similarly c-vectors are stored both in _BC and in _C.

  NOTE: This is currently done to ensure backwards compatibility. In a future ticket warnings will be set-up and then the old data structures will be phased out.

• In the initialization code there is a jungle of if statements. For example the lines in the __init__ command where self._G is defined could instead be

  try: self._G = data.g_matrix() except: pass

  while data.g_matrix() should take care of failing gracefully when the g-matrix can't be computed.

• Did you test how much slower and how much more space-demanding it is, for example, to keep track of c-matrices and g-matrices vs not keeping track of them? If the difference is not noticeable (and we think it will not be) it may be just better to always keep track of them, simplify the code and spare the user few boolean flags.

  NOTE: To be able to test whether or not this would speed up computations or free up space, this ticket implemented boolean flags as internal data that allow the user to keep track of less data as one mutates. After this is successfully merged into sage, we will keep track of whether this improves users' flexibility and computational speed. If it does not, we can revert to a version with less control and less overhead where all data is kept track of as we mutate.

• Similarly the various use_* functions (and few other bits and pieces) should never allow for inconsistent data. On the one hand it would not be mathematically correct, on the other it saves a lot of coding time and execution time because one can assume that the data structure is consistent and avoid all the checks that are repeatedly done right now.

  NOTE: This is currently done to ensure backwards compatibility with commands like reset_cluster and set_cluster. In these commands, the user can set cluster variables directly but in the new improved data structure, sage keeps track of g-vectors and F-polynomials instead. This is computationally better because Sage works faster with polynomials than rational functions. But at the moment, it would be difficult for the user to set F-polynomials directly or to have sage parse a user-chosen cluster into F-polynomials and g-vectors.

  NOTE: A future ticket by Salvatore Stella and Dylan Rupel will work directly with g-vectors and F-polynomials and would allow this parsing to occur.

• Is _sanitize_init_vars the same as (or similar to) sage.structure.parent.normalize_names ? If so it might be better to remove redundant code.

  NOTE: I checked this, and I do not believe they are since _sanitize_init_vars would also allow more complicated names like allowing [1,2,5] as a variable name which would be common in cluster algebra theory where Plucker coordinates are cluster variables and have such names.

• cluster_index should take as input a cluster variable not a string and it should actually raise an error if the input can't be cast to the right type automatically.

Gregg

[stumpc5]

Changed author from Aram Dermenjian to Aram Dermenjian, Gregg Musiker

[stumpc5]

comment:42

We gonna move forward!

[vbraun]

Changed branch from public/ticket/18594 to f257d82