Hi Mark!
On Tue, Mar 04, 2014 at 06:09:12PM -0500, Mark Shimozono wrote:
> I covet your thoughts on the following.
>
> It seems mostly hopeless to implement tensor products for random modules
> since this involves infinitely many generators and infinitely many relations.
> Therefore I will limit this discussion to ModulesWithBasis(R) for R a
> commutative ring with 1.
+1!
Just for the record: it's among Aladin's plans to implement tensor
products of the form V \tensor_A W where V and W are finite
dimensional modules with basis and A is a finite dimensional (or at
least finitely generated) algebra acting on V (on the right) and W (on
the left). With immediate application to compute induction of
modules. But it's an orthogonal feature.
> Right now the ring R is not in the category of ModulesWithBasis(R),
> so you can't tensor with it.
> Even though tensoring an R-module over R with R is isomorphic to
> doing nothing, it is desirable to be able to do this, for reasons given below.
I agree! And in the long run, it would be nice to be able to use the
tensor notation to extend the base ring. But that's another story.
> Therefore I propose that the category of ModulesWithBasis(R).TensorProducts()
> should supply a special object (the identity object in the category),
> implemented by a CombinatorialFreeModule over R with a single basis element.
> I suppose for AlgebrasWithBasis(R).TensorProducts()
> the same object would also know that it is an AlgebraWithBasis.
This could be a sensible approach.
Hmm, let's see, we would want every category to provide the relevant
methods for this object (like product_on_basis for
AlgebrasWithBasis). I guess we can live for now with a single class
implementing all the methods, and then we just specify in which
category the object lives depending on whether we start from
ModulesWithBasis, AlgebrasWithBasis, or ...
What would you use as index for the single basis element?
One issue: with the current implementation of tensor products, if O is
this object and V is a module with basis, the tensor product O \otimes
V will be isomorphic to V, but not equal; the index set will indeed
consist of the pairs (o,v) where o indexes the single basis element of
O and v runs from the indices for V. Do we want to "flatten" things
like we do for associativity? At this point I lean for yes, since we
do it for associativity. How do we detect when to flatten?
If we decide for flattening, and thus plan to have some code to handle
this special case, then maybe it would be simpler to take control
earlier on, and instead make a special case to directly handle R
\otimes V, without a need for introducing O in the first place.
>From a technical viewpoint, I would need to dig back in the code to
see how much work it would take in both cases, but I guess we are
better off taking the decision from a user interface point of view.
> This would allow (together with my tensor-of-maps construction)
> for the natural and easy construction of somewhat complicated morphisms.
> For example, lots of the maps occurring in Hopf algebra theory
> require the presence of R as an object with which to tensor.
>
> Moreover, if certain structure maps (say for Hopf algebras) were required to
> be
> module morphisms rather than trickly little functions,
> then it would be possible (in fact really easy) to do things like
> automatically
> provide Hopf structure on a tensor product, easily cobble together
> TestSuites to check commutativity of complicated diagrams
> involving tensoring, etc.
Yes! I definitely would love to see progress in that direction. In
MuPAD-Combinat, we could do things like:
> lra := LodayRoncoAlgebra():
> idTensorAntipode := lra::p::id # lra::p::antipode:
> checkAntipode := lra::p::mu @ idTensorAntipode @ lra::p::coproduct:
> t := lra::p::one;
> checkAntipode(t)
where `#` and `@` were the tensor product and composition operators,
and `::` was the analogue of `.` in Python.
That was made easier because in MuPAD one could specify the domain and
codomain of plain functions (like id, antipode, mu, coproduct), which
was a step toward making them into morphisms.
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/groups/opt_out.
