#8431: Substitutions over unit cube faces (Rauzy fractals)
--------------------------------------------------------------------------------+
Reporter: vdelecroix
| Owner: tjolivet
Type: task
| Status: needs_work
Priority: major
| Milestone: sage-4.6
Component: combinatorics
| Keywords: word morphism unit face generalized substitution rauzy fractal
Author: Vincent Delecroix, Timo Jolivet, Franco Saliola, Stepan Starosta
| Upstream: N/A
Reviewer:
| Merged:
Work_issues:
|
--------------------------------------------------------------------------------+
Comment(by slabbe):
Salut Timo,
I look at the patch and still have comments.
> * It changes the `plot_tikz` function. There are no more
`\newcommand`'s,
> but only `\def`'s that are inside the `tikzpicture` environment. (No
more
> global annoyance, and it should work fine with `sagetex` now.) Also,
RGB
> colors a printed with two decimals only.
Great for the `\def` instead of `\newcommand`.
> * In response to "the domain alphabet of the substitution used must
> correspond to the type of faces":
When I wrote that comment, I was meaning that I fixed it in my patch. In
fact, I removed the coercion of the face type into the integer ring which
allows the user to use the type of object he wants for the face types.
> now, every substitution defining an `E1Star` object is converted to an
> equivalent substitution on alphabet `'1'`, ..., `'d'`. The type of a
face can
> be specified by a positive integer or a string representing a positive
> integer, and is converted to a string when the `Face` object is created.
I do not agree with this. I do not want the type face to be converted to
an integer nor to a str. I want it to stays as it is given by the user. I
want the correspondance between the faces type and the domain alphabet of
the morphism to be clean. I do not want the correspondance appear by
coincidence. Here are three examples to clarify my point :
GOOD (integer faces type with integers for the domain of the substitution)
:
{{{
sage: from sage.combinat.e_one_star import E1Star, Face, Patch
sage: x = [Face((0,0,0),1), Face((0,0,0),2), Face((0,0,0),3)]
sage: P = Patch(x)
sage: sigma = WordMorphism({1:[1,2], 2:[1,3], 3:[1]})
sage: E = E1Star(sigma)
sage: E(P)
Patch: [[(1, 0, -1), 1]*, [(0, 1, -1), 2]*, [(0, 0, 0), 3]*, [(0, 0,
0), 1]*, [(0, 0, 0), 2]*]
}}}
GOOD (str faces type with str for the domain of the substitution) :
{{{
sage: from sage.combinat.e_one_star import E1Star, Face, Patch
sage: x = [Face((0,0,0),'1'), Face((0,0,0),'2'), Face((0,0,0),'3')]
sage: P = Patch(x)
sage: sigma = WordMorphism('1->12,2->13,3->1')
sage: E = E1Star(sigma)
sage: E(P)
Patch: [[(1, 0, -1), 1]*, [(0, 1, -1), 2]*, [(0, 0, 0), 3]*, [(0, 0,
0), 1]*, [(0, 0, 0), 2]*]
}}}
BAD (integer faces type with str for the domain of the substitution).
Correspondance is lost. If the following is suppported, it makes the code
less usable for potential future uses by others.
{{{
sage: from sage.combinat.e_one_star import E1Star, Face, Patch
sage: x = [Face((0,0,0),1), Face((0,0,0),2), Face((0,0,0),3)]
sage: P = Patch(x)
sage: sigma = WordMorphism('1->12,2->13,3->1')
sage: E = E1Star(sigma)
sage: E(P)
Patch: [[(1, 0, -1), 1]*, [(0, 1, -1), 2]*, [(0, 0, 0), 3]*, [(0, 0,
0), 1]*, [(0, 0, 0), 2]*]
}}}
The reason is that the code we write is *always* used differently by the
others. And the coercion of the face type to a str object is an
unneccessary restriction. Do you agree with me?
> This allows us to assume that the type of a face in 3D is in {`'1'`,
`'2'`,
> `'3'`}, which is very useful for plotting functions.
Can you explain me why it is useful for plotting functions? Is it because
digits can not be used in a definition like `\def\loz1{...}` ? But then, I
don't understand why `'1'` is better than `1`. I am sure we can find a
solution for the plotting problem that will not restrict the usability of
the code.
> * An option to color face according to their type has been added.
Thanks for fixing this in the `__call__` method. Small suggestions :
coloring='color_from_type' is redundant. I suggest that the following
{{{
- ``color_from_type`` - boolean (default: False). Colors the faces
according to their type.
}}}
becomes
{{{
- ``'face_type'`` - boolean (default: False). Colors the faces
according to their type.
}}}
For the `repaint` method. I dislike the addition of a new argument to the
function. The reason is that the user should never use the argument `cmap`
at the same time as the argument `color_from_type`. Hence, inconstencies
in the arguments can happen and should be considered. This tells us that
it should be only one argument that plays the role for either one or the
other. Python is great for that because it is not a typed language.
Moreover, I was disappointed that it is not possible for the user to
specify which color he can give to each faces type. Hence, I suggest to do
the following which should fix all the problems I mention::
{{{
def repaint(self, cmap='hsv'):
r"""
Repaint all the faces of self from the given color map.
This changes self.
INPUT:
- ``cmap`` - color map (default: 'hsv'). It can be one of the
following :
- string - A color map. For available color map names type:
``import
matplotlib.cm; matplotlib.cm.datad.keys()``. Each face will
be
given a color according to their rank in the patch.
- list - a list of color to assign to the faces in order.
- dict - a dict of faces type mapped to colors.
- ``{}``, the empty dict - the dict ``{'1':'red', '2':'green',
'3':'blue'}`` is used.
}}}
> * It is possible to choose whether to (or not to) print the
`tikzpicture`
> environment definition, and the `\def` macros.
Ok. And by default, they are printed : great.
> * Some other minor fixes, and small documentation fixes.
Great.
Finally, lines like
{{{
if print_macros == True:
}}}
should be replaced by
{{{
if print_macros:
}}}
That is it for now.
If you rework on it, you can reload your last patch or add a new one. It
is as you wish. I do not have any local modifications.
Cheers!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8431#comment:24>
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.
