Hi Andrew!
On Tue, Nov 11, 2014 at 03:07:26PM -0800, Andrew wrote:
> This is a good start but it is not enough: essentially the difference
> between what I want and what this does is the same as the difference
> between a vector space isomorphism and an A-module isomorphism. As you
> pointed out, there are limitations if these objects are algebras. The
> same limitations apply to modules because any interesting
> CombinatorialFreeModule will come equipped with endomorphisms, actions
> and other methods. I would like a mechanism for automatically
> transferring these methods to the new module by implicitly invoking the
> coercions above. These methods will be both module methods and module
> element methods and, more generally, algebra and algebra element
> methods.
> I don't think this this should be hard to do within the existing
> framework, and the mechanism should be roughly what you have above.
> After all, this is easy enough to do by hand because if F has a nice
> method then
>
> sage: G(F(G.an_element()).nice_method())
>
> transfers the method to G. The trick is to find an efficient, and
> seamless, way of doing this. If F is the original
> CombinatorialFreeModule (with distinguished basis), then the simplest
> hack would be to make __getattr__ in the class for G call the methods
> of F whenever they are not defined. So something like:
>
> def __getattr__(self, attr):
> try:
> return self(getattr(F(self), atttr))
> except AttributeError:
> pass
> raise AttributeError('{} has no attribute {}\n'.format(self,attr))
>
> The disadvantage of this approach is that it does not respect
> tab-completion and documentation, so it's probably going to be better
> to play some inheritance tricks.
> In terms of interface, I'd like to set up something like this:
> sage: G=F.new_basis([4,5,6],basis_to_new_basis=phi,
> new_basis_to_basis=psi,...)
> This should accept a subset of the CombinatorialFreeModule arguments
> (for example, basis_keys, prefix, ...), as well as coercions to other
> bases for the module. As I said I'll try and think more about this.
> This would certainly be useful for me. Let me know if it is unlikely to
> be useful for others.
Another disadvantage is that, given that methods in Python are not
typed, it's impossible to make a difference between methods that
return an element of G or of elsewhere, and add coercions as
appropriate. Hence a brute-force approach as above is likely to give
out wrong results. I believe we really need to write the wrapper
methods by hand.
The good news is that there already is infrastructure for this :-) It
works well in situations like this where there is a single parent one
wants to pull operations from through isomorphisms. Here I am
constructing a free module which is endowed with a Hopf algebra
structure by declaring it as isomorphic to the group algebra of the
symmetric group::
sage: G = SymmetricGroup(3)
sage: F = G.algebra(QQ)
sage: G = CombinatorialFreeModule(QQ, range(6),
category=HopfAlgebras(QQ).FiniteDimensional().WithBasis().IsomorphicObjects())
sage: G.retract = F.module_morphism(lambda g: G.monomial(G.rank (g)),
codomain=G)
sage: G.lift = C.module_morphism(lambda g: F.monomial(G.unrank(g)),
codomain=F)
sage: G.ambient = lambda : F
sage: G.an_element()^2
17*B[0] + 8*B[1] + 12*B[2] + 6*B[3] + 6*B[4]
This works because, once in the Sage code, it has been explained that
if G is a quotient (more generally a subquotient) of F, then a product
in G can be calculating by lifting to F and retracting back.
The following does not work yet, but it would be easy to add
appropriate methods for coalgebras in Coalgebras.Subquotients:
sage: C.an_element().coproduct()
*boom*
In general every category should eventually specify how its operation
pass to subobjects, quotients, etc.
The thematic tutorial I mentioned previously has a section with an
example like this.
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 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.
