#18594: Add additional mutation options for clusters
-------------------------------------+-------------------------------------
Reporter: aram.dermenjian | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.9
Component: combinatorics | Resolution:
Keywords: SageDays64.5, | Merged in:
clusters, mutation, seeds, quiver | Reviewers: Viviane Pons,
Authors: Aram Dermenjian | Christian Stump
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/ticket/18594 | f257d8224aa79c85a84ced0e69f378fafedbe546
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gmoose05):
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
--
Ticket URL: <http://trac.sagemath.org/ticket/18594#comment:41>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
