#15916: Tensors on free modules of finite rank
-------------------------------------+-------------------------------------
Reporter: egourgoulhon | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: linear algebra | Resolution:
Keywords: free module, | Merged in:
tensor, tensor product | Reviewers: Travis Scrimshaw
Authors: Eric Gourgoulhon, | Work issues:
Michal Bejger | Commit:
Report Upstream: N/A | 6e53a8d3c92d405541e2a21dff5a867d402937e6
Branch: | Stopgaps:
public/tensor_modules-15916 |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by egourgoulhon):
Replying to [comment:44 tscrim]:
> Finally, some time to do more review.
Thank you very much for this new piece of work!
>
> I'm thinking we should combine the `*morphismTensor` into the
`*morphism` methods and the make `FreeModuleTensor` a base class of
`FreeModuleHomset`. This should fix the need to skip part of the test
suite for those classes. Or did you get the dreaded "layout conflict"
error?
Actually, given that endomorphisms are now properly dealt with, as Maps,
with some coercion from type-(1,1) tensors, I am wondering about the
necessity to maintain the class `FreeModuleEndomorphismTensor`...
> >
> > Not done yet. Note however that transitivity is implemented in the
method `FreeModuleTensor.common_basis()`.
>
> I've had two thoughts about this. The first is pulling out the
functionality into a `DiGraph` instance where the vertices are bases and
the edges are the various transition maps, thus you could use the
`shorted_path` method. Also suppose you have a chain `A -> B -> C -> D`,
along the way you would need to compute `A -> C`, and I'm thinking we
should store that morphism (or leave it as an optional argument). Note
that you might have to make the transition matrices immutable.
Using digraphs for this sounds indeed appealing...
> > > - In Sage, the `view` function outputs as a pdf. So the name of the
`view()` method is confusing to me. Do you think we could change the name
to something else like `expand`?
> >
> > We thought quite a lot about the name of this method; here we really
need a short name, because it is used very often in interactive mode
(notebook). The idea is to display tensors in a nice human readable form,
but not to change their state, which something like `expand` might
suggest. `display` was too long. An alternative was `show` but we
eliminated it because in Sage it is used for graphic outputs. So the short
name that we ended with was `view`. We may also wonder why `view` should
be reserved for pdf output. Wouldn't `view_pdf` or `make_pdf` be more
suggestive ?
>
> IDK why it was chosen, but for better or worse, that's the current
standard. Also the name doesn't quite match what it does IMO. So I'd
really like a different name. Perhaps `display`, `print`, `equation`,
`peq` (short for `print_equation`), ...?
OK, maybe `display` is a good replacement of `view`. It is longer to
write, but one can always use TAB completion.
>
> > > - Fix all failures from the `TestSuite` or justify why we can skip
certain tests.
> >
> > Done. Some fixes consisted in initializing the objects (e.g. by
setting some components) prior to the !TestSuite. Note that
`_test_category` had to be skipped when constructing the object by a
direct call to `__init__`, since the correct construction must be
performed by a call to `parent().element_class`. In the latter case,
`_test_category` passed.
>
> These seem to indicate the need for a parent for these elements.
Not always, if I understand correctly. For elements that have a proper
parent, like `FreeModuleTensor`, the construction has to be performed by
`parent.element_class`, not by a direct call to
`FreeModuleTensor.__init__`, for `_test_category` to be passed (cf. the
doctest of `FreeModuleTensor.__init__`). If I am correct, this is a
general feature of Sage's category framework.
But for elements that are implemented as a subclass of `FreeModuleTensor`,
like `FreeModuleLinForm`, you are right: a proper parent is missing (see
below).
>For say the linear forms, you should just need a class
> {{{
> LinFormParent(TensorFreeModule):
> Element = FreeModuleLinForm
> }}}
> (with perhaps a `_repr_` stating its the set of all linear forms) and an
`if` statement when constructing the `TensorFreeModule`. This also means
they get the benefits from having a proper category. Do you mind doing
this?
Yes I will try. For `FreeModuleLinForm` there should be no problem.
However for `FreeModuleAltForm`, it seems we are facing the element
subclass issue discussed in [https://groups.google.com/forum/#!topic/sage-
devel/tZW9T-AixBQ this thread]. Indeed, not all type-(0,p) tensors are
alternating forms. Suppose one wants to compute A+B, with A an alternating
p-form and B a generic type-(0,p) tensor. Then A and B will have different
parents, so that `A._add_` cannot be called directly. Of course, one could
implement coercions from alternating p-forms to type-(0,p) tensors, but
this involves creating a new object from scratch, A' say, by copying the
components of A. For objects with a lot of components, in many different
bases, this may be not very efficient...
>
> Also could you change things like
> {{{
> "blah" + str(obj) + "foo"
> }}}
> to
> {{{
> "blah {} foo".format(obj)
> }}}
> (or if you prefer `"blah %s foo"%(obj,)`)? I believe this is more
pythonic, and it makes it a lot easier to read. Thanks.
OK, I will. Btw, besides being more pythonic, is there any technical
advantage in writing
`"blah {} foo".format(obj)` instead of `"blah" + str(obj) + "foo"`? IMHO,
the latter is more readable than the former.
--
Ticket URL: <http://trac.sagemath.org/ticket/15916#comment:45>
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/d/optout.
