#16851: Implement direct sum and tensor products for chain complexes and Koszul
complexes
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: algebraic | Resolution:
topology | Merged in:
Keywords: | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 01158352cb6751e7286023c3031ad1120fa3cca1
u/tscrim/koszul_complexes | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Thanks for taking a look at this!
I will make all of these changes once my Sage rebuilds (probably late
tonight or tomorrow).
Replying to [comment:3 jhpalmieri]:
> For `cartesian_product`, I think that the requirement that the degrees
of the differentials of the factors must agree is completely natural, but
it should be mentioned in the docstring and it should probably be
doctested. Same for `tensor`.
Good point. Will do.
> I think you can delete the line `zero = R.zero()` in
`cartesian_product`.
No, it's used when constructing the differentials.
> This is odd behavior when `subdivide=True` and there is more than one
factor:
> {{{
> sage: m = identity_matrix(QQ, 2)
> sage: C = ChainComplex({0:m})
> sage: ascii_art(C.cartesian_product([C,C], subdivide=True))
> [1 0 0 0|0 0]
> [0 1 0 0|0 0]
> [0 0 1 0|0 0]
> [0 0 0 1|0 0]
> [-------+---]
> [0 0 0 0|1 0]
> [0 0 0 0|0 1]
> 0 <-- C_1 <-------------- C_0 <-- 0
> }}}
> I was expecting the matrix to have subdivisions for each factor, not
just the last one. I guess iterating `matrix.block_diagonal` doesn't
preserve earlier subdivisions as you add more blocks.
I can fix this for the Cartesian product (which I could actually make
smarter and faster). Will change.
> Something similar happens with `tensor`.
This one I'm not entirely sure I can fix. Would you be okay with just a
`TODO` comment in the doc about this if I can't fix it?
> Should it be `tensor` or `tensor_product`?
The functorial construction is `tensor`, so I have to use that.
> In `cartesian_product`, is it worth pointing out that `subdivide` must
be specified explicitly? That is, you can't do `C.cartesian_product(D,
True)`.
Since it is part of the explicit arguments (which shows up under `?`), and
we expect the user to have a basic knowledge of python syntax, I don't
want to put any comments about this.
> In `koszul_complex.py`, is the dot intentional in
> {{{
>
###################################################.#####################
> }}}
No, that's a typo.
> In that file, people have different styles, but I prefer importing
functions only when you need them, not at the top-level. Having them at
the top-level could potentially slow down startup times, I think.
Importing them at the top-level makes the call to the function faster,
which is much more important in this case. However we can lazy import the
`koszul_complex.py` module, which we should do since I feel that it's not
likely too many people will use this.
> In the `__classcall_private__` method for Koszul complexes, I don't
understand the lines
> {{{
> if elements is None:
> elements = R
> if not elements:
> ...
> }}}
> If you call `KoszulComplex` with no arguments, you get an error before
you reach this stage, so I think the second `if` can be skipped. I also
gets various unhelpful error messages if I call `KoszulComplex(ZZ)` or
`KoszulComplex(QQ)` without specifying `elements`. Maybe if `elements` is
not specified, set it to an empty tuple instead? That is, if only one
argument is passed, if it's an iterable, set `R` to be the parent of the
first entry. Otherwise, set `R` to be that argument and set `elements` to
be `()`. Or something like that.
It was for passing in a list (tuple) of 0 elements. You are right and that
I should better handle when passing a base ring with no arguments. Will
fix.
> I was a little surprised that your code for Koszul complexes didn't use
the tensor product you had just defined. I'm guess that your way is
faster?
Yes, especially for large number of elements (I don't believe that my code
for the tensor product is fast at all and probably could be improved).
--
Ticket URL: <http://trac.sagemath.org/ticket/16851#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/d/optout.
