#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 tscrim):

 Replying to [comment:34 jhpalmieri]:
 > Replying to [comment:32 tscrim]:
 > > 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.

 Yea, I confirm that there is not much time being spent on the transpose by
 just pulling that part out to a separate line (which I should have done
 beforehand, sorry). So the way to optimize this further is to speed up the
 matrix construction, which might depend upon the input data, and then also
 the dot product is the 3rd slowest line. I think we've gotten to a good
 point that we should just let it be for now (at least I'm not going to try
 and optimize it further because I will be doing the refactoring below).

 > > 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.

 There is a way to access the part in a single degree with the `basis`
 function by passing in an integer:
 {{{
 sage: s = SymmetricFunctions(QQ).s()
 sage: list(s.basis(3))
 [s[3], s[2, 1], s[1, 1, 1]]
 }}}
 This unfortunately doesn't work for most of the infinite dimensional
 CFM's, but there should be a generic method that works for all objects in
 `FiniteDimensionalModulesWithBasis`. At which point, we can use the
 `submodule` to construct the degree part (which also should have a
 dedicated method):
 {{{
 sage: s.submodule(list(s.basis(3)), already_echelonized=True)
 Free module generated by {0, 1, 2} over Rational Field
 }}}

 > 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.)

 What we could do is specify variable names and then could use the
 `inject_variables` method. I will think more about this tomorrow when I
 work on the above refactoring.

--
Ticket URL: <http://trac.sagemath.org/ticket/6102#comment:35>
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.

Reply via email to