#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 tscrim):
Finally, some time to do more review. It's looking really good.
Replying to [comment:41 egourgoulhon]:
> Replying to [comment:38 tscrim]:
> > - Do we need the class `FormattedExpansion`? It doesn't seem to be
used.
>
> Yes, we need it: it is used by the method `view()` of classes
`FreeModuleTensor` and `FreeModuleAltForm`, to have a nice output, either
text formatted or LaTeX formatted (notebook).
Ah, I see (I never really use the notebook).
> > - Should we make the morphisms inherit from `Morphism` and/or have
their parents be some kind of `Homset`?
>
> This is done in the new commit. It introduces free module homomorphisms,
via
> - the parent class `FreeModuleHomset` (subclass of
`sage.categories.homset.Homset`)
> - the element class `FiniteRankFreeModuleMorphism` (subclass of
> `sage.categories.morphism.Morphism`)
> Coercions to/from type-(1,1) tensors have been introduced as well.
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?
> > but within that method, could we also check transitivity (there's a
method which does this already, but I forget what it's called)?
>
> 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.
> > - 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`), ...?
> > - 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. 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?
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.
--
Ticket URL: <http://trac.sagemath.org/ticket/15916#comment:44>
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.
