The main reason I don't like the SF-like solution for naming statistics (at
least in the way I can foresee it being implemented) is that you would need
to assign a variable in order to use tab completion:
m = d.maps()
m.<tab>
This is *ok*, but it seems quite awkward to me.
I think that your solution of having the extension immediately after maps
gets around this:
d.maps.<tab>
The problem here is that other combinatorial objects don't have this
behavior and you might be hiding the maps for a user that doesn't know they
are there.
I am getting less an less worried about this solution, because it is
exactly the point hiding the maps.
I was able to make an example of this behavior very easily.
In the file dyck_word.py, insert the following lines:
class DW_Maps_class():
"""
new class where all maps should go!
contains now two copies of the identity map.
"""
def __init__(self, dw):
self._parent = dw
def map1( self ):
return self
def map2( self ):
return self
class DyckWord_class(CombinatorialObject):
def __init__(self, l, latex_options={}):
CombinatorialObject.__init__(self, l)
self.maps = DW_Maps_class( self ) #### this is the magic line here
self._latex_options = dict(latex_options)
if "tikz_scale" not in self._latex_options:
self._latex_options["tikz_scale"] = 1
if "diagonal" not in self._latex_options:
self._latex_options["diagonal"] = False
if "line width" not in self._latex_options:
self._latex_options["line width"] =
2*self._latex_options["tikz_scale"]
if "color" not in self._latex_options:
self._latex_options["color"] = "black"
if "bounce path" not in self._latex_options:
self._latex_options["bounce path"] = False
if "peaks" not in self._latex_options:
self._latex_options["peaks"] = False
if "valleys" not in self._latex_options:
self._latex_options["valleys"] = False
Now when you compile this you get the following:
sage: D = DyckWord([1,0])
sage: D.maps.<tab>
D.maps.map1 D.maps.map2
sage: D.maps._parent == D
True
-Mike
On Friday, 22 June 2012 09:38:25 UTC-4, Anne Schilling wrote:
>
> Hi Christian,
>
> > I already asked this, but no one seemed to have an opinion on that...
> >
> > I have now implemented 5 or 6 bijections between Dyck paths and
> > subsets of permutations (pattern-avoiding or noncrossing). I think
> > that it is not practical to have a name for each of them since they 1.
> > do not necessarily have names in the literature and 2. the list of
> > methods for Dyck paths (and actually many other objects) becomes more
> > and more confusing in tab completion which I find not very user
> > friendly.
> >
> > I currently have
> >
> > DyckWord.to_permutation(bijection=None)
> >
> > and then the optional argument bijection is used to differ between the
> > bijections. But another solution would actually be to have
> >
> > sage: d = DyckWord([])
> > sage: d.to_permutation.<tab>
> >
> > yields a list of all possible maps
> >
> > and even more
> >
> > sage: d.statistics.<tab>
> >
> > yields a list of all combinatorial statistics (Anne actually requested
> > such a use case some time ago). Using this behavior would make the
> > statistics not appear directly when typing
> >
> > sage: d.<tab>
> >
> > Only statistics would appear here. The same maybe for maps, then we
> > would not have
> >
> > sage: d.to_permutation.<tab>
> >
> > but
> >
> > sage: d.maps.<tab>
> >
> > would give a list of maps and
> >
> > sage: d.maps.to_permutation.<tab>
> >
> > then the list of maps to permutations. This way, we would have a
> > better organization of the combinatorial maps and statistics (which
> > would be very helpful, I guess, if we keep implementing more and more
> > of these), and the tab completion becomes arranged in a user readable
> > way.
> >
> > a. what do you think about such a design?
>
> I think such a design is a good idea. I am not completely sure whether
>
> d.maps.to_permutation.<tab>
>
> is really needed. Perhaps
>
> d.to_permutation.<tab>
>
> is enough.
>
> > b. it seems to be not standard in object-oriented programming. what
> > are the down-sides?
> >
> > c. i would have no idea how to reach such an implementation.
>
> I think a similar implementation was recently done for symmetric
> functions, by doing
>
> sage: Sym = SymmetricFunctions(QQ['q','t'])
> sage: Mac = Sym.macdonald()
> sage: Ht = Mac.Ht()
>
> so you can probably look in /combinat/sf/ (with the new symmetric function
> patch applied)
> to see how it is done.
>
> Best,
>
> Anne
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/q8-Lf2WWAN0J.
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-combinat-devel?hl=en.
