#12996: Support for one-dimensional shifts of finite type
--------------------------------------+-------------------------------------
Reporter: mhs | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.9
Component: combinatorics | Resolution:
Keywords: symbolic dynamics | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Michael Schraudner | Merged in:
Dependencies: | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by slabbe):
1. The file {{{doc/en/reference/index.rst}}} changed in a recent version
of Sage. Hence, there is now a small reject with the first patch which
should be fixed :
{{{
sage-5.8/devel/sage-slabbe $ hg qpush
applying trac_12996_SFT_final_version-MHS.patch
patching file doc/en/reference/index.rst
Hunk #1 FAILED at 58
1 out of 1 hunks FAILED -- saving rejects to file
doc/en/reference/index.rst.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh trac_12996_SFT_final_version-
MHS.patch
10 slabbe@pol ~/Applications/sage-5.8/devel/sage-slabbe $ cat
doc/en/reference/index.rst.rej
--- index.rst
+++ index.rst
@@ -59,6 +59,7 @@
cryptography
logic
combinat/index
+ dynamics
numerical
probability
stats
}}}
2. The coverage of the folder {{{sage/dynamics/symbolic}}} is not 100% as
it should:
{{{
sage/dynamics/symbolic $ sage -coverage .
------------------------------------------------------------------------
No functions in ./__init__.py
------------------------------------------------------------------------
No functions in ./all.py
------------------------------------------------------------------------
SCORE ./finite_type_shift.py: 83.3% (35 of 42)
Missing documentation:
* line 129: def sft_warning_style(msg, category, filename, lineno,
file=None, line=None)
Missing doctests:
* line 2855: def _allwords(self, n)
* line 2879: def _check_alph(self, n)
* line 2915: def _create_empty(self)
* line 2934: def _create_edge_label_DiGraph(self)
* line 2972: def _create_vertex_label_DiGraph(self)
* line 3002: def _create_fwords_DiGraph(self)
------------------------------------------------------------------------
}}}
I know it is hidden functions and so on, but they should be documented and
doctested as any other.
3. I realize that the SFT, which can be created from three distinct input
types (digraph, matrix, forbidden words), compute everything at the
creation of the SFT. For example:
{{{
sage: X = SFT(["0101", "100"], alph=["0", "1"]) # computation of the
matrix is done here
sage: M = X.matrix() # not here
}}}
Since there is only one class for SFT, I understand why everything is
computed in the init. Because, we want to make sure once the init is done,
that every objects behave the same what ever input was given.
If I had to code such a class now, I would create four classes : `SFT`,
`SFT_from_digraph`, `SFT_from_matrix` and `SFT_from_forbidden_words`. I
would put methods that depends on the representation inside child classes
and general methods in the top class.
{{{
#!python
class SFT(SageObject):
def __classcall__(self, data):
if data is a digraph:
return SFT_from_digraph(data)
elif data is a matrix:
return SFT_from_matrix(data)
if data is forbidden words:
return SFT_from_forbidden_words(data)
def matrix(self):
raise NotImplementedError("this is a specific method and must be
coded in the child class")
def some_general_method(self):
pass
class SFT_from_digraph(SFT):
def __init__(self, data):
self._graph = data
def matrix(self):
M = ... # compute the matrix from the graph
return M
class SFT_from_matrix(SFT):
def __init__(self, data):
self._matrix = datta
def matrix(self):
return self._matrix
class SFT_from_forbidden_words(SFT):
def __init__(self, data):
self._forbidden = data
def matrix(self)
M = ... #compute the matrix from forbidden words
return M
}}}
The advantage is that the code is closer to the reality (more clear,
easier to maintain) and also more efficient (the matrix, for above
example, is computed only if the user needs it).
This ticket is open since too long time. I feel bad for asking such
modifications... Should we just make it get into Sage and make future
improvements then? I am sure the code is usefull as it is now so...
Sébastien
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12996#comment:42>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
