#19634: Implement Hochschild (co)homology
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.1
Component: algebra | Resolution:
Keywords: Hochschild, | Merged in:
homology, chain complexes | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 005ced0b48cf670718148b4a8e948aabf06a8163
public/homology/hochschild-19634 | Stopgaps:
Dependencies: #19609, #19613, |
#19608 |
-------------------------------------+-------------------------------------
Changes (by tscrim):
* status: new => needs_review
* keywords: => Hochschild, homology, chain complexes
* dependencies: #19609, #19608 => #19609, #19613, #19608
* component: categories => algebra
* milestone: sage-6.10 => sage-7.1
Comment:
Replying to [comment:2 jhpalmieri]:
> Hi Travis, I'm finally getting around to looking at this.
Thanks!
> I have some issues with the documentation. I don't have much experience
with Hochschild homology, so some of these may just be my own ignorance.
I don't so much either, but I felt this provided a nice test case for
infinite chain complexes (two of the things I'd like to eventually get
would be group and Lie algebra (co)homology).
> - If you're working over a base ring ''R'' which is not a field, do
things go wrong if ''M'' is not projective as an ''R''-module?
I have no idea. Wikipedia was the most general reference as (IIRC) all of
the other references I had found either assumed ''R'' was a field or made
some implicit assumption (i.e., the base ring of the algebra was not
specified).
> - I think the face maps ''d_i'' would be better without signs, and then
the boundary map would be their alternating sum (as the Wikipedia page
says). The point is that the unsigned face maps would be part of a
simplicial structure.
Good point; changed. I also added the part about the simplicial structure
to the doc.
> - When you mention Tor and Ext, they should be over the ring ''A^e^'',
the tensor product of ''A'' and ''A^op^'', instead of ''A''.
Fixed.
> Looking at the code, I wonder if it would be better to use Sage's
`ChainComplex` class, at least when computing homology: to compute
homology in dimension ''d'', construct the chain complex by
> {{{
> C = ChainComplex({d: self.boundary(d).matrix(), d+1:
self.boundary(d+1).matrix()}, degree_of_differential=-1)
> }}}
> Then compute `C.homology(d)` and lift the answer back to the original
Hochschild complex. I didn't try any kind of lifting, but it seemed that
constructing `C` and then computing `C.homology(d)` was faster than
directly computing `HH.homology(d)`, at least in the cases I tried. One
possible advantage is that if some day we speed up computations with
general chain complexes, then this class would benefit.
I agree that it is both faster and avoids duplication. In an ideal world,
we would have everything under a single class hierarchy, but I think that
will probably require a fair bit of refactoring. I left my code as a
fallback because the chain complex code currently requires working over a
field or '''Z''', and, a priori, it does not require it. (It currently
fails for doing the symmetric group algebra over '''Q'''[''x''], but this
could easily be fixed by making the diagonal entries `1` if they are
units.)
I also merged in #19613 because I used it for testing things (and it will
be in the next beta).
--
Ticket URL: <http://trac.sagemath.org/ticket/19634#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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
