Oops. I didn't try out my identity maps, but I realized that they should
really be returning
return self._parent
and not self...
-Mike
On Saturday, 23 June 2012 08:23:20 UTC-4, Mike Zabrocki wrote:
>
> 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/-/2cJhARjoBO8J.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
