#9877: Add is_sturmian_factor, is_tangent methods for finite words
-----------------------------+----------------------------------------------
Reporter: tmonteil | Owner: tmonteil
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.6
Component: combinatorics | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------------+----------------------------------------------
Comment(by tmonteil):
Replying to [comment:3 abmasse]:
> There is another problem with your function:
{{{
[cut]
TypeError: Your word must be defined on a binary alphabet
}}}
>
> I think this shouldn't be the case. In fact, this is interesting,
because it raises another problem I had when working on another patch.
What I suggest is that you could first verify if the parent has size 2
and, if it's not the case, you check if its *real* alphabet has size 2 by
using the expression
> len(set(self)) == 2
>
> I think the clean solution would be to replace the deprecated function
`alphabet()` by a new one that would compute the *real alphabet* in
question, so that there would be two kinds of alphabet:
>
> 1. The one corresponding to the parent of the word (for instance `aaab`
might be a word defined on the alphabet `{a,b,c}`).
> 2. The one corresponding to the alphabet realized by the word
`Alph(aaab) = {a,b}`
>
> The first one is called by `w.parent().alphabet()` while the second one
would be obtained from `w.alphabet()`. But this is for another ticket.
>
> What I suggest is that you simply add the `len(set(w)) == 2` condition
to your code and we'll clean it eventually.
Since it is explained in the documentation, this is not a bug but a
feature ;)
I was thinking about this alphabet problem, and i am willing to write a
ticket about that issue. I think that such a decision should be made for
the whole word directory, with its whole community. Here are some bits.
If i start to do such tests in such a method, then almost every method of
the FiniteWords class will have to do it as well, and the faster
parent().alphabet() method will become useless. So there is a problem of
code replication.
Another problem is that a test like `len(set(w)) == 2` takes probably a
linear time whereas `size_of_alphabet` is just looking into the parent,
which is constant time.
Some programmer (user) should know where his/her words are living and
should be warned if not. Making "friendly code" does not mean to pass over
dirty programmer's inconsistencies, because then it won't detect the clean
programmer's mistakes anymore. Fore those lazy ways of programming, we can
imagine a global option which tells how the methods should care about the
alphabet, so that both kinds of behavior are possible.
As for me, this may look Bourbachist (in particular not `bash`-ist ;), but
i would like the empty word defined on a 2-letter alphabet to be
recognized as a factor of a Sturmian word and not necessarily the empty
word defined on a three letter alphabet (or at least to be warned if i do
so). This may be, a contrario, an argument to make a difference between
`is_sturmian_factor` (or `is_finite_sturmian`) and `is_balanced(1)`.
If in some very few occasion, the user will indeed need to use such a
method on some words defined on some non-two-letter alphabet, but then
there should be some general coerce methods like `redefine_alphabet` or
`minimize_alphabet_to_actually_used_letters` that s-he can use in his/her
code.
Another example of why the alphabet question deals with the whole `word`
directory, and why there should be an overall policy is the following:
{{{
sage: words.LowerMechanicalWord(1/sqrt(2)).parent()
Words
sage: words.CharacteristicSturmianWord(1/sqrt(2)).parent()
Words over Ordered Alphabet [0, 1]
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9877#comment:9>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
