#15726: Implement tensor modules and algebras
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: algebra | Resolution:
Keywords: tensor module | Merged in:
algebra | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 49c7a792f3bc8e0a08d82eafe178652cd3a9b034
public/algebras/tensor_algebra-15726| Stopgaps:
Dependencies: #15289 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Hi Travis!
Thanks for your work on free monoids and algebras; those features have
been waiting around for too long! I glanced through the code, and here are
some random thoughts that came to my mind:
- Rather than importing {{{IndexedFreeMonoid}}} in the global namespace,
it would be preferable to have {{{FreeMonoid(...)}}} construct an
{{{IndexedFreeMonoid}}} when given appropriate arguments (and same
things for its friends). Let's avoid the bad route we took with
{{{CombinatorialFreeModule}}} and have at once a single entry point for
free monoids! As an immediate side effect, the current code for
the {{{FreeAlgebra}}} might well make it almost immediately work for any
index set.
- Mathematically speaking, the free algebra indexed by I is
(isomorphic to) the algebra of the free monoid indexed by I is
(isomorphic to) the tensor algebra of the free module indexed by I. So
we now have three implementations of the free algebra!
I'd rather only have a single implementation, typically in
{{{FreeAlgebra(K, I)}}}, with {{{FreeMonoid(I).algebra(K)}}}
pointing to it.
{{{FreeAlgebra(K, I)}}} should by the way be in the category
Monoids().Algebras(K) which could allow for reusing some generic
code.
{{{TensorAlgebra(V)}}} could then also point to {{{FreeAlgebra(K, I)}}}.
Possibly with some customization (e.g. printing using tensor symbol).
By the way, with the name {{{TensorAlgebra}}}, the user would probably
expect to write the product using tensor rather than *. Actually I
am not yet sure we actually want at this point to have
{{{TensorAlgebra}}} with multiplicative notation.
Altogether, since {{{TensorAlgebra}}} does not bring a feature set
really different from {{{FreeAlgebra}}}, I'd rather leave it name alone
for now until we have a better view on how we want to handle
tensor/symmetric/exterior modules.
- It could be preferable to have {{{TensorModule}}} be a functorial
construction, parallel to that for tensor products, and if
possible sharing as much code as possible with it.
- On a similar footing, the code for _repr_, _latex_, ... in
{{{TensorModule}}} is duplicated from
{{{CombinatorialFreeModule_Tensor}}}. Can we avoid that?
- {{{IndexedFreeAbelianGroup}}}: do we want to write them additively or
multiplicatively? In the later case, code could be shared with
{{{CombinatorialFreeModule}}}.
- {{{TensorModule.algebra}}}: this definition of .algebra is incompatible
with the functorial construction with the same name
({{{I.algebra()}}} builds an algebra whose basis is indexed by
I). Do we really need this method?
- {{{is_finite}}} methods for {{{Free...Monoid}}}: this would be
best achieved by setting the category appropriately.
- {{{IndexedMonoidElement}}}: Describe the data structure
- The doctests of __init__ actually constructs an
{{{IndexedFreeAbelianMonoid}}}. Is this on purpose?
- {{{_mul_(self, y)}}} -> {{{_mul_(self, other)}}}
- What is the semantic of comparisons (__lt__, ...)? Do we really
need those comparisons?
- __pow__: Can't we use a generic implementation?
- IndexedMonoid.__contains__ seems generic enough to be lifted
higher up in the class hierarchy
- _an_element_: rather do the product of the first three elements
(if available), similar to what's done in
CombinatorialFreeModule.an_element. This is less demanding on the
index set (computing the cardinality may be expensive/not
implemented)
- gens: using {{{PoorManMap}}} in {{{CombinatorialFreeModule.monomial}}}
is relevant to make it easy to allow for the short idiom:
{{{M.module_morphism(M.monomial*...)}}}. Do we need it here?
- gens: define instead monoid_generators. gens defers by default to
monoid_generators in the monoids category (at least with #10963).
- ngens: kill the beast. {{{self.gens().cardinality()}}} is a better
idiom. If we really want a shortcut, it should live in a more
generic setting.
--
Ticket URL: <http://trac.sagemath.org/ticket/15726#comment:4>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
