On May 7, 2008, at 5:50 AM, David Kohel wrote:
> Hi,
>
>>> Given algebras A and B, I would return C and the two maps m1: A -> C
>>> and m2: B -> C:
>>
>>> (C, m1, m2) = A.tensor_product(B,ring=R)
>>
>> I might prefer to have something like
>>
>> C = A.tensor_product(B, ring=R)
>>
>> and then one can do
>>
>> C.coerce_map_from(A)
>> C.coerce_map_from(B)
>
> This would require a new tensor product class in order to represent C.
I think this is a good thing, as then one could ask for its factors,
etc.
> I think it might be desirable when taking the tensor product of two
> matrix algebras to return a matrix algebra, or when taking a tensor
> product of two polynomial rings to return a polynomial ring.
> The other option is to have a genuine class which wraps these
> rings as you indicate.
The wrapper class is already implemented. As for the tensor product
of two polynomial rings being a polynomial ring, for example, it
essentially will be (it'll have all the same methods, and should be
useable anywhere a polynomial ring is), just have some additional
structure on top.
>
> The suggested syntax above, and here:
>
>> One would rarely need the maps themselves, as one
>> could do C(a) and C(b), or even c + a, and the coercion model would
>> handle it all well (here a, b, and c live in A, B, and C resp. of
>> course).
>
> assumes that A is distinct from B (or that there are no canonical
> coercions from A to B or vice versa).
True, though if A *is* exactly the left of right term, one could
return the correct half.
> However a common
> construction is precisely to form a self tensor product or power
> C = \otimes_{i=1}^n A, in which case the choice of the 2 or n
> maps A -> C can not be decided by without specification of
> the map.
Yep, there should be a method for getting a morphism that takes which
factor one wants to land in.
>> C would probably be implemented one of David Roe's wrapper
>> classes, so Q tensor Z[x] would be Q[x], but would still know its
>> factors.
>
> A good design is very important.
I agree here.
> In fact this is a vey generic categorical construction of (a sum or
> coproduct in the category of rings). We should first consider how
> general products and coproducts should be constructed, and set
> up a common infrastructure and syntax. It needs to be (1) easy
> and natural to use, (2) mathematically correct and complete.
And (3) (if possible) efficient.
> The homomorphisms for products and coproducts are essential
> parts of the construction so they should be an accessible part
> of the design. The homomorphisms themselves should be fast
> to apply, and their design should take into account canonical
> homomorphisms.
Certainly. We are putting a lot more infrastructure in place to do
generic operations like this.
- Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
