On 2/16/12 3:26 PM, Nicolas M. Thiery wrote: > On Thu, Feb 16, 2012 at 07:41:52AM -0800, Anne Schilling wrote: >> But how do I do this? Implementing the analogue of the cores method (see >> combinat-queue) >> I get ... >> TypeError: __init__() got an unexpected keyword argument 'parent' > > See my reviewer's patch. The __init__ method of LinearExtensionOfPoset > needed to be updated too to expect a parent as input.
Thank you so much! So that I understand for the future: __init__ always needs to take parent as an input for the element class? But it does not need to take all inputs that would be needed for a class call? Since right now the poset is not passed in as an argument in __init__. This is achieved through __classcall___. Why did the parent method in this case also need a __classcall_private__? Is it because of the optional variables that are passed in? > I threw in a couple further comments. Thank you. I dealt with all of them and added more code. > The one thing I am confused > about is the optional argument "order". What does it mean? It's not > actually used anywhere in the code. Do you need some sort of relative > linear extensions for your research? Currently sage seems to randomly choose a linear extension for a given poset. However, it is much nicer if the specified poset P corresponds to the identity linear extension. See for example: sage: P = Poset(([1,2,3,4,5,6,7], [[1,2],[1,4],[2,3],[2,5],[3,6],[4,7],[5,6]]), cover_relations = True) sage: p = LinearExtensionOfPoset([1,2,3,4,5,6,7],P) sage: p.order() (1, 2, 3, 5, 6, 4, 7) I prefer to assign the linear extension [1,2,3,4,5,6,7] to P. Having `order` was my way of dealing with this randomness. Order is used in the code: see to_poset. > Good interface design shall be guided by what we want as users in the > long run, not by the technical hurdles we are encountering at a given > point :-) > > So the question is: what is it that we want, as users? I do not find it so unnatural to have P.linear_extension() and P.linear_extensions(). If P.linear_extensions() becomes the list of LinearExtensionsOfPoset, then what should linear_extension become? I as a user would prefer to assign the identity to P as a linear extension. > By the way: changing P.linear_extensions() to return an enumerated set > rather than a plain list could make sense, assuming there is no speed > loss. This might require a bit of cythonification; maybe using > ClonableArray will be enough. It's slightly backward incompatible (it > does not print the same). Why did you make the choice to print differently in ClonableArray as opposed to CombinatorialObject? Cheers, Anne -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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.
