#15916: Tensors on free modules of finite rank
-------------------------------------+-------------------------------------
Reporter: egourgoulhon | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.5
Component: linear algebra | Resolution:
Keywords: free module, | Merged in:
tensor, tensor product | Reviewers: Travis Scrimshaw
Authors: Eric Gourgoulhon, | Work issues: documentation
Michal Bejger | Commit:
Report Upstream: N/A | 6e53a8d3c92d405541e2a21dff5a867d402937e6
Branch: | Stopgaps:
public/tensor_modules-15916 |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:45 egourgoulhon]:
> > 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`...
We're on the same wavelength. Hopefully there won't be a (very annoying)
technical issue with python being unable to figure out the MRO.
> Using digraphs for this sounds indeed appealing...
Let me know if you have any questions.
> OK, maybe `display` is a good replacement of `view`. It is longer to
write, but one can always use TAB completion.
The more I think about it, the more I like `display`. Thanks for changing
it.
> > 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...
I guess the question is how often do you expect to do this? Plus I suspect
a lot of the data can just be referenced, not copied, since the data is
(essentially) immutable. It's not much different than other parts of Sage
and having to be careful about parents. For instance:
{{{
sage: %timeit ZZ(1) + QQ(1)
100000 loops, best of 3: 10.4 µs per loop
sage: %timeit ZZ(1) + QQ(1)
100000 loops, best of 3: 9.73 µs per loop
sage: %timeit QQ(1) + QQ(1)
100000 loops, best of 3: 6.53 µs per loop
sage: %timeit QQ(1) + QQ(1)
100000 loops, best of 3: 7.22 µs per loop
}}}
The issue is to minimize the penalty. A benefit from doing the
implementation is you can add two alternating forms and get an alternating
form (for free I believe).
> > 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.
The `"blah %s foo"%obj` is the fastest (not by too much), but if `obj` is
a tuple, an error gets raised (the wrapping `(obj,)` gets rid of this for
marginal penalty). The `format` allows you to do fancier things like
repeating objects, for some time, the `%` syntax was deprecated in python3
for `format` (again, not anymore), and it's on the same order of speed as
using `+`'s. So really there's no real technical advantage other than
readability (all python code I've previously seen used the `%` and more
recently `format`, but to be honest, recent python code has all be Sage).
Somewhat unrelated, I do miss the C++ `cout<<"blah"<<obj<<"foo"`...
Last I agree with Jeroen, especially comment:47.
Thanks again for your work on all of this.
--
Ticket URL: <http://trac.sagemath.org/ticket/15916#comment:48>
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.
