Nicolas, > > Therefore I propose that the category of > > ModulesWithBasis(R).TensorProducts() > > should supply a special object
I think the strongest argument for making a special tensor unit object O is for transparency and consistency. If we want to support Hom for ModulesWithBasis(R).TensorProducts() and obey general categorical rules, then there is no choice but to allow some form of R as an object in this category. For example, the counit of a coalgebra has codomain R. It seems that we don't want R to be both a ring and the unit tensor object. Therefore we need O. Also, O cannot in general disappear entirely for the user. For example, the tensor of two scalar-valued maps (maybe they are traces or somesuch) has codomain O. There might be some lively debate on whether we should essentially allow automatic "conversion of category" between R and O. To me this sounds convenient but iffy. For example, anywhere (especially when making actual morphisms or declaring membership in a Hom) that O should appear, the user might try to use R, clashing with the category rules. How should the user ask for O? And the related question: > What would you use as index for the single basis element? I vote that it should be some shorthand for the identity element of R. > 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. I am strongly leaning for "yes" too. However I already argued why O cannot entirely disappear. A final reason to have O. We certainly don't want to flatten away random user-created free-R-module tensor factors that "accidentally" have rank 1. How can we tell which to flatten? My answer: those that are equal to O! We need to include the following in documentation of tensor products: "Sage automatically applies the associativity and unit isomorphisms of tensor products as follows ..." Here are some details involved with tensor-of-maps in the presence of auto-flattening. The code must distinguish between the following kinds of tensor factors: 1. A module (key is a single "element") 2. A tensor product of modules (key is a tuple) 3. R (key is "empty" or 1_R or somesuch) Already we have cases 1 and 2, and this knowledge is necessary to convert from the key sets of the tensor factors, to the flattened one of the tensor product, and vice versa. This is needed to know the correct form for the input of a morphism. Tensor products of maps f_i \in Hom(M_i,N_i) must know about all this stuff for each tensor factor of the domain and the codomain. Tensoring with f_i have these special cases: 1. M_i=N_i=R: no effect 2. M_i = R: tensor with the constant module element f_i(1_R) in the slot of N_i (up to linearity) 3. N_i = R: scalar multiply by f_i 4. Otherwise, the usual thing. Well, this isn't so bad ... > 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. Going between functions and morphisms is one of the banes of this tensor-of-maps business... --Mark -- 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.
