#6102: cohomology ring of simplicial complexes
-------------------------------------+-------------------------------------
Reporter: bantieau | Owner: bantieau
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: algebraic | Resolution:
topology | Merged in:
Keywords: | Reviewers: Travis Scrimshaw
Authors: John Palmieri | Work issues:
Report Upstream: N/A | Commit:
Branch: u/tscrim/AT-model | 716469ac9519fc492467d4a635c80468880df94d
Dependencies: #19179 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by jhpalmieri):
Replying to [comment:32 tscrim]:
> I made some reviewer changes, and it's mostly tweaking docstrings and
copying your sparse/dense hack to get another ~20% in the "new" version.
Great.
> From taking a closer look at things, I bet we could get further speedups
by not taking the transpose of the `phi_old` and `pi_old` matrices in the
inner loops and using `v * M` multiplication instead of `M' * v`. I tried
to do this, but I don't think I understand the interworkings of the code
to get this to work (at least for the "new" version). Have you tried to do
this?
Good idea. I just tried it and it led to no improvement, surprisingly,
over the rationals, and a slow-down in characteristic 2. Maybe the lack of
improvement is not that surprising, since I had already moved the slow
matrix constructions out of the inner-most loops, so they don't get
executed as much. And maybe taking the transpose is not slow compared to
the rest of matrix construction.
> Also I noticed that `HomologyVectorSpaceWithBasis` represents a graded
piece of the (co)homology space. Would you be opposed to me rewriting that
such that it becomes the full (co)homology space/ring? I think it would
simplify the overall code structure, allow easier extensions to infinite
simplicial/cell complexes, and give a better interpretation of
`cup_product` as being the product in the cohomology ring. (Also with
#18175, we could then give work towards a cap product for manifolds.)
I think that it is natural to want both structures, the cohomology in a
single degree and the cohomology in total. If you want to rewrite this
part, that's okay with me. If you want to think about the most natural way
to access cohomology classes, too, go ahead. I am not completely satisfied
with
{{{
sage: a,b,c,d = X.cohomology_with_basis(1, QQ).gens()
}}}
Maybe
{{{
sage: H.<x> = X.cohomology_with_basis(1, QQ)
}}}
will define `x0`, ..., `x3` if the cohomology is 4-dimensional? Or x10,
..., x13? (The problem with the angle-bracket notation is that we
shouldn't have to know how many generators there are ahead of time.)
> I didn't mean to imply that it wasn't a significant speedup and I
apologize if I did. However that is a much larger difference than I really
expected. Eeek!
No need to apologize, you had a reasonable question. And it is surprising
how much difference that single change makes.
--
Ticket URL: <http://trac.sagemath.org/ticket/6102#comment:34>
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.
