On Jun 23, 10:40 pm, "Nicolas M. Thiery" <nicolas.thi...@u-psud.fr>
wrote:
> On Wed, Jun 23, 2010 at 05:40:04PM -0700, John H Palmieri wrote:
> > (I would raise an error unless each monomial has the same degree:
> > degree for elements of a general graded algebra should only be defined
> > for homogeneous elements.)
>
> 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.
> Otherwise, I am indeed fine with the following:
>
> assert self.is_homogeneous()
> return self.parent().degree_on_basis(self.leading_support())
>
> which becomes constant time when assertion tests are turned off.
>
> > > �- Could WeightedIntegerVectors(d, degrees) possibly replace
> > > � �basis_function(d, degrees)?
>
> > More or less. I think I'll redefine basis_function so that it returns
> > WeightedIntegerVectors(d, degrees).list().
>
> What's the rationale for forcing the list? This makes it expensive to
> compute with elements of large degree (say, getting the homogeneous
> component of x^100 in 5 variables of degree 1 requires listing 4598126
> elements).
Because without forcing the list, the TestSuite fails. If I do
self._basis_fcn = partial(WeightedIntegerVectors, weight=degrees)
CombinatorialFreeModule.__init__(self, R,
Family(NN, self._basis_fcn),
category=GradedAlgebrasWithBasis(R))
then associativity fails, for example. I think it's trying to multiply
a single WeightedIntegerVector with a set of WeightIntegerVectors, and
of course this causes problems. I don't know why it's trying to
perform this multiplication, but if I put some print statements into
the product_on_basis routine, then one of the two arguments might be
"(0,0)"
and the other might be
"Integer vectors of 0 weighted by (2, 3)"
??
> > I was actually doing it to force coercion of the coefficient into the
> > base ring:
>
> > sage: A = AlgebrasWithBasis(GF(2)).example()
> > sage: A.from_base_ring(12)
> > 12*B[word: ]
> > sage: A.from_base_ring(12) == 0
> > False
>
> > That's a bug, too, I guess.
>
> This one is by design. from_base_ring is responsible for implementing
> the morphism from GF(2) to self. It's the job of coercion to build
> from it the morphism from ZZ:
Oh, I see. I think I saw a remark in the "term" function for
CombinatorialFreeModules about them not forcing coercion on
coefficients, and got carried away.
--
John
--
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.
