Clifford algebras and differential Weyl algebras

[tscrim]

Initial implementations of Weyl and Clifford algebras.

Depends on #16037

CC: @darijgr @sagetrac-sage-combinat

Component: algebra

Keywords: days54

Author: Travis Scrimshaw

Branch/Commit: ff27bdc

Reviewer: Darij Grinberg, John Palmieri

Issue created by migration from https://trac.sagemath.org/ticket/15300

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from a2354c6 to 8914ccc

[darijgr]

comment:36

OK, enough for today. I've left you a question in the latest commit.

Also, what exactly does this do?

        E = super(ExteriorAlgebra, cls).__classcall__(cls, R, names)

I thought it would classcall cls as a CliffordAlgebra, but then shouldn't it give it a quadratic form?

---

New commits:

8914ccc

further clifford edits

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

37f6cbf	Added coboundary operator.
2a4ca79	Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 8914ccc to 2a4ca79

[tscrim]

comment:38

I've added a cohomology part as well, but there's still some tweaks left to do.

That passes to the __classcall__ (not __classcall_private__) of the class CliffordAlgebra, which just ends up constructing the object.

[darijgr]

comment:39

Yes, but wouldn't that method require passing it a quadratic form? Or am I confusing it with __init__?

[darijgr]

comment:40

Loads of doctests fail currently. Is this a WIP or have you changed some class names without changing references to them?

Also, I feel like more info is needed on what s_coeff represents and how it should be given.

[tscrim]

comment:41

You're confusing it with __init__().

It's currently a WIP. I had to push from my home computer and was in a slight rush to get out the door. I'll add some more info on s_coeff too.

[tscrim]

Dependencies: #16037

[tscrim]

comment:42

Found a bug with the hashing of Family: I could get equal families with unequal hashes. This stems from the fact that keys() from (python) dicts aren't necessarily sorted. I'm almost done, but not quite yet.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

4665988	update dot2tex to latest dev version
702c72b	form valid keys for dot2tex
e8abf26	fix more doctest failures
289c212	pointless bikeshedding of tarball name
0c5b4f8	pyparsing is deprecating itself
ad62d43	delete previous dot2tex directory if it exists
f6e95b4	Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
e5cde4c	Some fixes for doctests.
44ae929	Hash function for families.
c470f1c	Merge branch 'public/combinat/hash_family-16037' into public/algebras/weyl_clifford-15300

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 2a4ca79 to c470f1c

[tscrim]

comment:44

Ack, #16026 somehow as gotten in there. I'll fix it later.

[darijgr]

comment:45

Oh, so __classcall__ just serves to typecast the object into the right class?

I'll continue looking at the code tomorrow, as today I barely have any time left. I'm done looking at the Clifford algebra classes, and I'll look at the Exterior algebra classes once you're done implementing homology; so the next step is likely to be the general Weyl algebra. If I'll have any troubles with the OOP (I imagine there might be issues with making differential Weyl algebras inherit from Weyl algebras), I'll let you know.

[tscrim]

comment:46

Well, to parse the input into a standard form and then create the object using those standardized inputs (or sometimes to emulate a factory).

It's done. The only thing left is some documentation and to make the exterior algebra more functor-like, and I should get that done tonight.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from c470f1c to a1628e2

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

66fc007	Some fixes for doctests.
c2f851b	Merge branch 'public/combinat/hash_family-16037' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
2c5afd8	More documentation and extended functorial-ness of exterior algebras.
a1628e2	Documentation fixes.

[tscrim]

comment:48

Okay, fixed. I'm also done making changes.

[darijgr]

comment:49

Any idea what to do about this?

sage: Q = QuadraticForm(ZZ, 3, [1,2,3,4,5,6])
sage: Qp = QuadraticForm(Integers(3), 3, [1,2,3,4,5,6])
sage: Cl = CliffordAlgebra(Q)
sage: Clp = CliffordAlgebra(Qp)
sage: a = Cl.basis()[(1,2)]
sage: a
e1*e2
sage: Clp(a) # so far so good
e1*e2
sage: Clp(3*a) # but now
0*e1*e2
sage: Clp(3*a) == 0 # not good!
False

I wouldn't be surprised if other covariant functors had the same bug...

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from a1628e2 to a6a7206

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

8589eb3	Merge branch 'public/algebras/weyl_clifford-15300' of git://trac.sagemath.org/sage into clifford
a6a7206	simple fixes, including yesterday's ones

[tscrim]

comment:51

It's coming from the fact that terms with coefficients of 0 aren't always being removed (like they should be). So it's something with the module morphisms, either that it's how we construct the module morphisms or in _element_constructor_.

[jhpalmieri]

comment:52

Random comments and questions:

Note that when you're using CombinatorialFreeModule, you shouldn't need both _repr_term and _repr_ for elements: just use _repr_term. You should also delete the _latex_ method for elements.

For the function repr_from_monomials, I wonder if repr_lincomb (defined in sage.misc.latex) does kind of the same thing?

By the way, can you compute the centers of any of these algebras? If so, having a method which returns it would be very nice.

[tscrim]

comment:53

Replying to @jhpalmieri:

Note that when you're using CombinatorialFreeModule, you shouldn't need both _repr_term and _repr_ for elements: just use _repr_term. You should also delete the _latex_ method for elements.

If I didn't override _repr_, it wouldn't redirect to repr_from_monomials (it goes to repr_lincomb).

For the function repr_from_monomials, I wonder if repr_lincomb (defined in sage.misc.latex) does kind of the same thing?

As I recall, repr_lincomb doesn't have as nice of printing (IMO) as repr_from_monomials with regard to spacing with the base ring being a polynomial ring.

By the way, can you compute the centers of any of these algebras? If so, having a method which returns it would be very nice.

A counter question, do you want the honest center or the supercenter of the Clifford/exterior algebra?

For the honest center, it should be trivial (given there is an even and odd element) since given an odd x and even y, we have xy = -yx + LOT. The exterior algebra is supercommutative, so its supercenter is the entire algebra. For general Clifford algebras, my first thought is it would correspond to rows of 0 in the quadratic form, but IDK off the top of my head for certain.

Edit - IDK off the top of my head either for the Weyl algebra. Darij, do you know what the (super)centers are to any of these?

[darijgr]

comment:54

This is actually more complicated than you think (and I have made lots of mistakes when working with these centers). See http://math.stackexchange.com/questions/129183/center-of-clifford-algebra-depending-on-the-parity-of-dim-v . I'd say let's wait until we have finite-dimensional algebras in Sage (or do we already?), since the center is not usually spanned by a subset of the standard basis.

[tscrim]

comment:55

Arbitrary finite (dimensional) algebras given by multiplication tables were done in #12141.

[darijgr]

comment:56

Oh; what I meant was algebras without a pre-chosen basis. There is no good canonical choice for a basis of the center of the Clifford algebra, unless the vector space comes with an orthogonal basis.

[tscrim]

comment:57

I think a part of #15916 would be something to that effect.

[jhpalmieri]

comment:58

Replying to @tscrim:

Replying to @jhpalmieri:

For the function repr_from_monomials, I wonder if repr_lincomb (defined in sage.misc.latex) does kind of the same thing?

As I recall, repr_lincomb doesn't have as nice of printing (IMO) as repr_from_monomials with regard to spacing with the base ring being a polynomial ring.

It seems like it would be better to fix repr_lincomb than to add new code which reproduces a lot of its functionality. How should a user decide which of these to use, if they're both available? But maybe I'm missing something.

By the way, can you compute the centers of any of these algebras? If so, having a method which returns it would be very nice.

A counter question, do you want the honest center or the supercenter of the Clifford/exterior algebra?

I meant the honest center. For exterior algebras, this is easy: it's the evenly graded part. For Clifford algebras, these are finite dimensional, so what happens if you try to solve the linear algebra problem (find all solutions to [x,-]=0 for all generators x)? You could try to do the same with the supercenter.

[tscrim]

comment:59

Replying to @jhpalmieri:

It seems like it would be better to fix repr_lincomb than to add new code which reproduces a lot of its functionality. How should a user decide which of these to use, if they're both available? But maybe I'm missing something.

I haven't checked to see how many doctests would need to be fixed, but I was worried it was a lot. I'll look into it.

I meant the honest center. For exterior algebras, this is easy: it's the evenly graded part. For Clifford algebras, these are finite dimensional, so what happens if you try to solve the linear algebra problem (find all solutions to [x,-]=0 for all generators x)? You could try to do the same with the supercenter.

Ack, you're right. I really shouldn't try to do math in my head late at night. I'll work the centers into this ticket as well.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from a6a7206 to 3c66a3f

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

3c66a3f

fix coercion of zero coordinates

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

52a13d9

correct typing in lift_morphism

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 3c66a3f to 52a13d9

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

d8c17dc

-1 useless line

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 52a13d9 to d8c17dc

[darijgr]

comment:63

Sorry for my slowness. I just fixed a bug in which the on_basis part of the lift_morphism morphism was using the domain instead of the codomain as parent. Don't you find it weird that it worked before? I do. The on_basis function would throw an IndexError whenever called on a nonempty sequence, but for some reason the module morphism worked. Maybe cython methods thwart exceptions? I can't explain this in any other way. (The cython method here is dict_linear_combination in sage/combinat/dict_addition.pyx. It is called by the linear_combination method. Now that I have changed the linear_combination call to a _from_dict one, the wrong parent wouldn't work anymore.)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from d8c17dc to 18b9529

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

18b9529

correct definition of coproduct

[darijgr]

comment:65

Travis, which definition of the interior product are you using? I'm asking because there are probably several (at the very least, there is a right-left issue, and there is the question which is the multiplier and which is the multiplied).

[darijgr]

comment:66

Also, are you fine with my edits to the CliffordAlgebra and CliffordAlgebraElement classes? If so, I could clone them to make Weyl algebras (the general case).

[tscrim]

comment:67

I think you should do:

• if self.base_ring() is R: in _element_constructor_ instead of the ==.
• Move the unshuffle out into combinat/combinat.py since it is a general (low-level) operation.
• Is using the remove_zeros option the fastest, as opposed to doing the != R.zero() check (which probably should be pulled out?)

Otherwise your changes look good. For the interior product, I'm using the definition I gave (the other one should be equivalent to the first one...) with \alpha as x.

PS - John, I'm still working on the centers.

[darijgr]

comment:68

Is this a reasonable speed test?

sage: R = PolynomialRing(QQ, 'x')
sage: Q = QuadraticForm(R, 3, [1,2,3,4,5,6])
sage: Cl.<x,y,z> = CliffordAlgebra(Q)
sage: d = {(0,1): R.gens()[0], (1,2): R.zero(), (0,2): R.one()}
sage: %timeit Cl._from_dict(d, remove_zeros=True)
100000 loops, best of 3: 5.32 µs per loop
sage: l = (((0,1), R.gens()[0]), ((1,2), R.zero()), ((0,2), R.one()))
sage: %timeit Cl._from_dict({m: k for (m, k) in l if k != 0})
10000 loops, best of 3: 23.8 µs per loop
sage: %timeit Cl.sum_of_terms(l, distinct=True)
100000 loops, best of 3: 7.36 µs per loop

(I've misnamed the variables but this shouldn't matter...)

Where should the unshuffle go?

[darijgr]

comment:69

Ooooh, now I see the definition of the internal product that you gave. I was looking at the wrong docstring.

[tscrim]

comment:70

Replying to @tscrim:

... into combinat/combinat.py

We should probably have internal_product_on_basis reference Element.internal_product.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 18b9529 to 651d063

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

689bce2	identity instead of equality for base rings
651d063	some clarifications on interior product

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 651d063 to de4cc8c

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

de4cc8c

another try at sphinx

[darijgr]

comment:73

I have done some improvements on the interior product. But I still need to reiterate my question: How is the interior product defined? You define it only when one of the two factors (the "smaller" one) is a single vector; but the method is defined for any two wedges. You seem to be reading the factor left-to-right, but a point can be made for the opposite convention. If you can give a reference, that's fine -- just please let's not leave this undocumented.

Should I generally use identity to compare base rings? I thought equality was more robust, or can we assume parents to be UniqueRepresentation?...

Sorry for ongoing lameness; I got some kind of cold again and my QSym paper is not progressing :/