Hi! In order to create a right module over a path algebra P, with a vector space basis given by the potentially infinite family of paths starting at some vertex, I thought I'd start with CombinatorialFreeModule.
My expectation was that it would work *easily* and out of the box, if - one provides a "family" B of basis vectors, where B is just an iterable container (i.e. one can test if something is in B, and one can list its elements) - the stuff that is in B can be multiplied from the right by monomials of P (i.e., paths), such that either a new element of B or None results. I.e., linearity is taken care of by generic code in CombinatorialFreeModule. However, it turns out that this is not enough: If "p in B", and M is CombinatorialFreeModule(QQ, B), then still M(p) fails, because at some point it is attempted to do B(p), after checking that indeed "p in B". But of course a container isn't necessarily callable. On the one hand, I wonder why the conversion into an element of B is needed after testing p in B. On the other hand, I wonder what other hidden assumptions exist on B. Apparently it needs a __call__ method. Or does B actually need to be a Parent (such as LazyFamily is a Parent)? Is it specified somewhere what assumptions are made? And: Is my expectation correct that in order to get the right-P-module structure, all what we need is that the elements of P have a .monomial_coefficients() method returning a dict, so that the elements of B can be multiplied with the keys of the dict? If not, where is it specified what is needed? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
