On Sat, Mar 26, 2011 at 06:00:50AM -0700, Simon King wrote: > Thank you! That was what I was looking for.
Indeed, that's one of the first tutorial we run during our Sage-Combinat days :-) We really need to get our collection of tutorials in Sage. There are just some Sphinx technicalities that we need to resolve with Florent. > Some comments: I would expect that monomial_coefficients() (or better > a different name that is backwards compatible, see below!) is a > required abstract element method of the category of ModulesWithBasis, > on top of which there is a default implementation of support(), > monomials(), coefficients(). Is that planned? Yes, definitely. In MuPAD all of those were in the categories rather than the specific implementation. It has just not been lifted up yet: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/ModuleWithBasis.mu?revision=7608&view=markup See also the extensive tests in: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/DOMAIN/TEST/FreeModule.tst?revision=7608&view=markup > And is it possible to change the names of these methods at this point? > > For example, shouldn't we better use dict() rather than > monomial_coefficients()? Namely, this is how the corresponding method > is called for polynomials: > sage: P.<a,b,c> = PolynomialRing(QQ) > sage: p = (a+b)^2 > sage: p.dict() > {(1, 1, 0): 2, (2, 0, 0): 1, (0, 2, 0): 1} > > And rather than always returning an actual dictionary or list by > e.dict() resp e.monomial_coefficients() or by e.coefficients(), > wouldn't it be a good idea to have an iterator e.iter_items(), > e.iter_coefficients() etc? I am also in favor of deprecating monomial_coefficients. In fact we do not necessarily need to replace it with something else, since, basically as you suggest, one can already do: dict(x) Indeed x.__iter__() iterates through the items of x. In fact the idiom we mostly use is: for (i, c) in x: ... Now, there is an issue about whether x.__iter__() should iterate through the items of x (as is the case currently), through the keys/support of x (as for a dictionary): sage: t = {'a':1, 'b':2} sage: list(t) ['a', 'b'] Or through the values of x (as for FreeModule elements): sage: F = FreeModule(QQ,3) sage: F.an_element() (1, 0, 0) sage: list(F.an_element()) [1, 0, 0] I could live with using as main idiom: for (i,c) in x.items(): ... or possibly (though conceptually not as nice): for (i,c) in x.iteritems(): ... > Moreover, in the case of a module, I wouldn't use the name "monomial" > for the basis elements. Is there a better name than "e.monomials()" if > e is an element of a ModuleWithBasis? Perhaps *this* should be called > "e.support()", whereas the indices of the support should be named > "e.support_indices()" or "e.indices_of_support()". We have a backlog of 10 years of using those conventions; so I'd rather stick to them as much as possible :-) Besides, it's good to stay close to the usual conventions for polynomials. Finally, I myself really consider that the support is made of the elements indexing the non zero monomials. Very much like the support of a function f: A -> B consists of the elements of A such that f(B) != 0. > Is it planned to also have a parent method, say, _element_from_dict_, > with the property P._element_from_dict_(e.dict())==e for any e in P? > The default implementation for a ModuleWithBasis could be: > def _element_from_dict_(self, D): > B = self.basis() > return self.sum([c*B[m] for m,c in D.iteritems()]) Definitely: sage: F = CombinatorialFreeModule(QQ, ZZ) sage: F._from_dict <bound method CombinatorialFreeModule_with_category._from_dict of Free module generated by Integer Ring over Rational Field> I would be fine making it more official as F.from_dict. See also the constructors F.sum_of_monomials, F.sum_of_terms, F.linear_combinations. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> http://Nicolas.Thiery.name/ -- 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.
