Hi Jason, On Tue, Jan 12, 2010 at 06:05:06PM -0500, Jason Bandlow wrote: > > - self._monomial_coefficients is specific to the > > CombinatorialFreeModule implementation. But you can use directly > > x[k] to get the coefficient of k in an element x of a module with > > basis. > > Very good to know. Do you know how I can get the list of all basis > elements which appear in x? Will x.support() work?
Yes! The standard ModulesWithBasis methods ought to be listed and documented in the category, either as abstract_methods or as default implementations. Please see the attached document I had written with Mike when he implemented CombinatorialFreeModule (and that I should have advertised). It contains a (preliminary/to be cleaned up) list of standard ModulesWithBasis methods. See also: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/ModulesWithBasis.mu?view=markup http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/DOC/ModuleWithBasis.mupdoc?view=markup http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/TEST/ModuleWithBasis.tst?view=markup > > By the way, at some point, we should have an > > ModulesWithBasis(...).example(), with a very minimal implementation > > to catch this kind of things in tests. > > Agreed. I'll try to create this too. (It will be another good way for > me to learn more about Categories). Cool, thanks! You can have a look in ModulesWithBasis.tst above for a (too minimal) example; it just had to implement fromList (replaced by from_dict in Sage), toList (replaced by __iter__ in Sage), coeff, and monomial. For Sage's minimal example, I'd suggest KK^n (where KK is the base_ring of the module with basis, and n defaults to, say, 4), with elements represented as lists of n elements of KK. > > Now, we hit the question of what a term is, and what a monomial is. > > We currently use MuPAD's convention that x^3 is a term, while 2*x^3 > > is a monomial. But other system use the reverse convention. > > I think Sage already has the reverse convention. If f=2*x^3*y^2 in a > MultiPolynomialRing, f.lc() currently returns 2 and f.lm() currently > returns x^3*y^2. The SymbolicRing seems to have methods > leading_coefficient() and trailing_coefficient(), along with > not-very-shortcuts leading/trailing_coeff(), which take a single > variable as input and return everything which is multiplied by that > variable in the first term in which that variable appears. A > UnivariatePolynomialRing seems to have leading_coefficient() but nothing > else. I had looked at these before, but your comment prompted me to > look further. I found this in the doc of > sage.rings.polynomial.toy_d_basis (written by Martin Albrecht): > > The notion of 'term' and 'monomial' in [BW93]_ is swapped from the > notion of those words in Sage (or the other way around, however you > prefer it). In Sage a term is a monomial multiplied by a > coefficient, while in [BW93]_ a monomial is a term multiplied by a > coefficient. Also, what is called LM (the leading monomial) in > Sage is called HT (the head term) in [BW93]_. > > So, as I understand it, > > 3 * x^2 : term > 3 : coefficient > x^2 : monomial > > would be consistent with the rest of Sage. Do you know of someplace in > Sage that is not consistent with that? Not on top of my head. But a systematic search is in order. It would be worthwhile to include embedded software in the search. Singular and Magma seem to use the same convention as Sage (term = c * monomial): http://www.singular.uni-kl.de/Manual/3-1-0/sing_231.htm#SEC272 http://magma.maths.usyd.edu.au/magma/htmlhelp/text313.htm#1968 > > It's kind of the last occasion we have to change that; it might > > actually be too late. Still, could you raise the issue on sage-devel? > > Do you still think so? Thinking twice about it, the change should not be that bad, since term is current essentially monomial with a default second argument coeff=1; so we can swap the two while maintaining backward compatibility. The other functions that should be fixed as well (sum_of_terms/sum_of_monomials, ...) are not that many, and I don't expect them to have been used much outside of our patches. > If you do, and if you can answer my previous question, I am happy to > do this. Great, thanks! For the record: I added in PS a discussion with the MuPAD team in ... 1998 ..., about the same issue :-) I would love to see it resolved once for all. Please make a call on sage-devel, and if there is a consensus for standardizing for term = coeff * monomial, go ahead with the change! I'd suggest a first patch/ticket doing the change, and then your triangularity patch on top of it. I am happy to review all of this promptly. It would be good to have all of this in Sage before Sage days 20 at the end of February. > > maybe x.leading_item, consistent with items/iteritems/... of > > dictionaries? > > You're right. Maybe x._leading_item or x._leading_mc ? Or do you think > this should also be exposed? More generally, which of the eight methods > (leading/trailing_coeff/monomial/term/items) should or should not be public? I would make them all public. So x.leading_<tab> lists all of them for you to choose the most appropriate for your use case. By the way: - leading_support / leading_coeff / leading_item are the most important ones programmaticaly. leading_monomial / leading_term are quite usual in other software, but I find them not that useful in practice. We could almost drop them. > Ooh, that sounds nice. Maybe I would call the attribute > self._dominant_term to avoid the confusion of leading_term meaning > trailing_term(). Sounds good. > I know I haven't responded to all your points here, but now it's time > for dinner. :) Thanks again for your help. Thanks again for taking over all of this. It relieves my todo list from yet another thing that was dying to be done. Enjoy your dinner (probably night by now)! Cheers, Nicolas PS: thanks for fixing yet another "readily" of mine in the doc :-) PS2: ------------------------------------------------------------------------------ From: Stefan Wehmeier <stef...@plato.uni-paderborn.de> To: nicolas.thi...@jonas.univ-lyon1.fr, sv...@plato.uni-paderborn.de Cc: stef...@mupad.de Subject: Re: Polynoms >>Nicolas Thiery (Isil) wrote: >>> >>> I would like to know if there is a strong convention for what >>> is a "term" and what is "monomial" in a polynomial. In MuPAD, this >>> seems to be "term" without coefficient, and "monomial" with >>> coefficient (monomial = coefficient * term): >>> ------------------------------------------------------------------------------ >>> >> lterm(2*x); >>> x >>> >>> >> lmonomial(2*x); >>> 2x >>> ------------------------------------------------------------------------------ >>> >>> On the other hand, I have been looking in several books. In general, >>> they just ignore the distiction term/monomial. In the following books >>> - Ideals Varieties and Algorithm (Cox Little and O'Shea) >>> - Commutative Algebra (Eisenbud, p.13) >>> the inverse convention is used (term = coefficient * monomial) >>> >>> So ? >>> In the lectures I heard, the same convention was used as in MuPAD, and Becker/Weispfennig, "Groebner bases" agrees with this convention. From the etymological viewpoint, this sounds logical because poly nomoi is plural of (ho) monos nomos, so if a monomial was defined by having coefficient 1, then in a polynomial (= "many (mon)nomials"), all coefficients would have to equal 1, too. Maybe you start a discussion in sci.math ? :-) Greetings, Stefan -- 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-de...@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.
