[sage-combinat-devel] Re: [sage-algebra] Re: an example of a graded algebra with basis
Hi John, Franco, Jason, Florent, ... I finally worked on the example of graded algebra with basis! See #9280. There are still things to settle (see the TODO's). I also need to reread our former discussions, which could possibly raise a couple more TODO's. #9280 depends on #10193: Add the category of GradedEnumeratedSets. It may accidently depend on other stuff in the Sage-Combinat queue. 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-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.
[sage-combinat-devel] Re: [sage-algebra] Re: an example of a graded algebra with basis
On Thu, Jun 24, 2010 at 6:40 PM, Nicolas M. Thiery
nicolas.thi...@u-psud.fr wrote:
On Thu, Jun 24, 2010 at 01:00:44PM -0700, John H Palmieri wrote:
What about two methods, degree and max_degree? (The second being
defined only when the indexing set is naturally ordered.)
I'd be happy with that. Then depending on the situation, people could
set degree equal to max_degree or have them be distinct.
It's interesting to see how different use cases we can have :-)
I can go with the above as a starter. Most likely we will set degree =
max_degree quite often, and when we will have a precise idea of the
perimeter of the use cases, we will put this in an appropriate
category.
Great. That's settled. Both degree and max_degree.
In principle this is fine, but I'm sure I've seen situations where
it's zero. Here's a sort of stupid situation:
sage: A = GradedAlgebrasWithBasis(QQ).example(generators=(x, y),
degrees=(2, 3))
sage: a = A.term((2,3), 0)
sage: a.monomial_coefficients()
{(2, 3): 0}
- d[mono] should be an element of R, so you don't need to coerce it into R.
Well, a method like term(tuple, coeff) doesn't coerce coeff to be in
R: if I work over GF(2) instead of QQ, then a = A.term((2,3), 12)
should equal zero (although it doesn't) and it should be ignored when
computing degrees. I suppose this is a mistake by the user (me),
since the documentation for term says that the coefficient should be
in the base ring, but still.
For this example code, I'd rather have the code be overly careful at
the expense of being efficient.
This is a huge bug. This is the datatype, so we can assume it meets its
specifications (that the coefficients are all non-zero and all belong to
the ring). Otherwise, the code will get cumbersome with checks of
coefficients being non-zero and ring containment, not to mention the
redundancy in checking the coefficients repeatedly. The element
construction mechanism should take care of this once and for all (and it
should have an option to bypass these checks).
Here is another bad example:
sage: s = SFASchur(ZZ)
sage: a = s._from_dict({Partition([1]):0})
sage: a
0
sage: dict(a)
{[1]: 0}
sage: a = s.element_class(s,{Partition([1]):1/2})
sage: a
1/2*s[1]
In light of this, I understand John's apprehension to avoid coercing and
checking of coefficients, but I maintain this is a bug. Do others agree?
Should I open a ticket?
Ok, we should document that passing 0 as coeff is an abuse of
A.term. And there probably should be an assertion check in A.term (as
well as for the requirement of the coeff to be in the base ring).
+1 for the assertion check in A.term.
- It is more efficient to check the degree of a monomial as soon as you
compute it rather than computing them all and then comparing. Here is
some code that does this.
monomials = self.monomial_coefficients().keys()
if monomials:
deg = self.parent().degree_on_basis
d = deg(monomials.pop())
return all(deg(mono)==d for mono in monomials)
else:
return True
I really should mark monomial_coefficients() to be deprecated in favor
of iteration and other accessors.
for (i, c) in self: ...
I didn't know about this! Cool.
The code above also has the inconvenient to force a copy of the list
of indices (in particular because of the write access). The following
variant leaves the door (in a future optimized implementation of
FreeModules) to run through the indices in-place:
degree = None
deg = self.parent().degree_on_basis()
for i in self.support():
if degree is None:
degree = deg(i)
elif deg(i) != degree:
return False
return True
I chose self.monomial_coefficients().keys() over self.support() because the
later returned a sorted list and in this case we don't care about sorting.
Again, this is generic code that should be lifted. Perhaps we should start
working on this lifting. Do we need a GradedCombinatorialFreeModule? or
does this belong to some category? probably both?
I think that the category GradedModuleWithBasis would seem like a
natural place to start, but other people know this part of the Sage
library a lot better than I do.
This definitely belongs to
GradedModuleWithBasis. (Combinatorial)FreeModule is really just a
specific (but useful!) implementation of the data structure and very
low level accessors for free module and their elements.
If someone else wants to start working on the lifting, please cc me
(jhpalmieri) on any relevant tickets. I don't think I'll be working
on it soon.
If no one beats me to review this ticket, I'll do that in my
reviewer's patch. But that won't be before about two weeks ...
I volunteer to review the reviewer's patch.
Franco
--
--
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] Re: [sage-algebra] Re: an example of a graded algebra with basis
On Thu, Jun 24, 2010 at 12:31 PM, John H Palmieri jhpalmier...@gmail.com wrote: On Jun 24, 12:23 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Wed, Jun 23, 2010 at 11:06:40PM -0700, John H Palmieri wrote: If the grading is over NN/ZZ, or some naturally ordered monoid, I would definitely argue for keeping degree for all elements. That's not how I think of elements of a Z-graded algebra: in my experience, if they're not homogeneous, then they don't have a degree. It should probably be left as a case-by-case situation. Well, certainly not case by case, since for most of our graded algebras (and we will have lots of them) we definitely want to have a degree function for all elements. But maybe that should be just in a subcategory (most of our algebras are actually graded connected over NN). What makes you dislike having degree implemented for all elements? - That it could be accidently used on non homogeneous elements by the caller, when not meant to, without an error raised? Yes, or that mathematically, at least some people would view degree as being undefined except on homogeneous elements, and I would want Sage to reflect that. If someone tells me that an element of a graded algebra has degree d, then I expect it to be homogeneous: I expect it to give a well-defined action, raising degree by d, on any graded module over that graded algebra. If someone says that they have a degree d polynomial, then I understand that this just means that the leading term is homogeneous of degree d, but if they say they have a degree d element in the polynomial ring k[x,y,z] graded by ..., then I interpret this to be a homogeneous element. (By if they say, I really mean, if I read this in a paper dealing with graded algebras. For example, if X is a topological space and H^*(X) is its cohomology, then if someone talks about a degree d element of H^*(X), they are almost guaranteed, in my experience, to mean a *homogeneous* element of degree d of H^*(X).) I'm leaving my example as is: non-homogeneous elements don't have a well-defined degree. But I'm also including a comment about this choice in the docstring. What about two methods, degree and max_degree? (The second being defined only when the indexing set is naturally ordered.) - That the specs might be ill-defined for non homogeneous elements (e.g. if the order is not total)? - That there is a faster way to do it for homogeneous elements (assuming we don't check for homogeneity)? Because without forcing the list, the TestSuite fails. Ah ok. Then that's just a bug that should be investigated and fixed. Let me know when you have an updated patch on trac, and I'll have a look. It's posted now: http://trac.sagemath.org/sage_trac/ticket/9280 I've taken a quick look, and have some comments on your code for is_homogenous: R = self.base_ring() d = self.monomial_coefficients() if len(d) == 0: return True deg_list = [self.parent().degree_on_basis(mono) for mono in d if R(d[mono]) != 0] return max(deg_list) == min(deg_list) - d[mono] should never, ever, be 0, so you can safely remove that check. - d[mono] should be an element of R, so you don't need to coerce it into R. - It is more efficient to check the degree of a monomial as soon as you compute it rather than computing them all and then comparing. Here is some code that does this. monomials = self.monomial_coefficients().keys() if monomials: deg = self.parent().degree_on_basis d = deg(monomials.pop()) return all(deg(mono)==d for mono in monomials) else: return True Again, this is generic code that should be lifted. Perhaps we should start working on this lifting. Do we need a GradedCombinatorialFreeModule? or does this belong to some category? probably both? Franco -- -- 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.
[sage-combinat-devel] Re: [sage-algebra] Re: an example of a graded algebra with basis
On Wed, Jun 23, 2010 at 03:13:39PM -0700, Simon King wrote: For example: sage: sf = SymmetricFunctions(QQ) sage: s = sf.schur() sage: s[3] s[3] This returns an element of the algebra, ... ... and I am very surprised that it does! I think this is wrong, and it is very inconsistent with the rest of Sage. Elements of s should be constructed via s(3) (hence, using _element_constructor_), certainly not via s[3]. Please all read SymmetricFunctions?. It is explicitly stated that this is a parent specific abuse of notation: As this is rather cumbersome, the following abuses of notation are allowed:: sage: p[Partition([2, 1, 1])] p[2, 1, 1] sage: p[[2, 1, 1]] p[2, 1, 1] sage: p[2, 1, 1] p[2, 1, 1] It just turn out that, in this specific context, users are very much expecting this notation. Certainly no general rule should be made from that. Best, 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-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.
