I don't care much about names either... In your 1., you say "An element of Multipartition() will be CombinatorialClass-es which wrap lists of Partition_class()" do you mean tuples, maybe? It is pedantic, but relevant in light of #11414. One should just decide on which is more useful to have in the end. Paul
On Thu, Jun 2, 2011 at 4:17 PM, Andrew Mathas <andrew.mat...@gmail.com> wrote: > > >> PartitionTuples is actually used, in some of my programs and now one >> time in patch #11412, and further in patch #11414 (submitted day >> before yesterday). > > Hi Paul, > > Currently it is just a suggestion to rename PartitionTuples as > Multipartions. Whether or not this actually happens depends on how > everyone feels about it. Personally, I prefer Multipartition but I can > live with PartitionTuples :) > >> If one wants to give all partitions of given weight, but indexed >> through their core and quotient, it makes sense to use PartitionTuples >> to index the quotients. > > Yes, I do this too in quite a bit of my (gap) code. My motivation for > working on this is that I need more functionality for multipartitions > than is currently available. Essentially, I want to extend a lot of > the symmetric group combinatorics for partitions to the class of > Multipartitions/PartitionTuples. Current functionality shouldn't be > lost and, if anything, it will become easier as there will be more > methods available and new classes for individual multipartitions which > are element classes for the existing classes for sets of > multipartitions. Whether or not the name is changed I'll have to make > sure that my changes don't break existing code, including your > patches. And then my code will only be accepted if its reviewers think > it's an improvement:) > >> A note on deprec(i)ation: is there a formal description somewhere of >> that process? > > I just looked and found: > http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.deprecated_function_alias > There is some discussion about the depreciation policy in sage-devel. > To summarise, functions should only be depreciated if there is general > agreement; backward compatibility should be maintained unless there > are good reasons not to; depreciated code should carry a warning of > teir empending depreciation for at least one year before it is > removed. > > Andrew > > -- > 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. > > -- 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.
