Opened 6 years ago

Closed 5 years ago

#15300 closed enhancement (fixed)

Clifford algebras and differential Weyl algebras

Reported by: tscrim Owned by: tscrim
Priority: major Milestone: sage-6.4
Component: algebra Keywords: days54
Cc: darij, sage-combinat Merged in:
Authors: Travis Scrimshaw Reviewers: Darij Grinberg, John Palmieri
Report Upstream: N/A Work issues:
Branch: ff27bdc (Commits) Commit: ff27bdc5d87967d0e7fd5c1305cef4340db816c7
Dependencies: #16037 Stopgaps:

Description (last modified by darij)

Initial implementations of Weyl and Clifford algebras.

Attachments (2)

trac_15300-weyl_clifford_algebras-ts.patch (42.4 KB) - added by tscrim 6 years ago.
trac_15300-todos-dg.patch (15.3 KB) - added by darij 6 years ago.

Download all attachments as: .zip

Change History (168)

comment:1 Changed 6 years ago by tscrim

  • Status changed from new to needs_review

comment:2 Changed 6 years ago by darij

  • Cc darij sage-combinat added

Changed 6 years ago by tscrim

comment:3 Changed 6 years ago by mguaypaq

  • Branch set to u/mguaypaq/weyl-clifford
  • Created changed from 10/16/13 23:16:37 to 10/16/13 23:16:37
  • Modified changed from 11/02/13 04:48:00 to 11/02/13 04:48:00

comment:4 Changed 6 years ago by bump

  • Branch changed from u/mguaypaq/weyl-clifford to u/bump/ticket/15300

comment:5 Changed 6 years ago by darij

  • Description modified (diff)
  • Modified changed from 11/05/13 22:56:47 to 11/05/13 22:56:47

comment:6 Changed 6 years ago by aschilling

  • Branch changed from u/bump/ticket/15300 to u/aschilling/ticket/15300
  • Commit set to e3ff430ec720208e5f3635c28ef9f707b2c362f1

New commits:

[changeset:e3ff430]Merge branch 'u/bump/ticket/15300' of git://trac.sagemath.org/sage into ticket/15300
[changeset:427f2fe]changed formatting of list
[changeset:0734921]changed spaces
[changeset:1c7458a]#15300: Implement Weyl and Clifford algebras.

comment:7 Changed 6 years ago by darij

  • Branch changed from u/aschilling/ticket/15300 to u/darij/ticket/15300
  • Modified changed from 11/05/13 23:12:51 to 11/05/13 23:12:51

comment:8 Changed 6 years ago by darij

  • Description modified (diff)

comment:9 Changed 6 years ago by gmoose05

  • Branch changed from u/darij/ticket/15300 to u/gmoose05/ticket/15300
  • Modified changed from 11/05/13 23:35:33 to 11/05/13 23:35:33

Changed 6 years ago by darij

comment:10 Changed 6 years ago by darij

  • Commit changed from e3ff430ec720208e5f3635c28ef9f707b2c362f1 to 8138949135606946e05c9dbf13a31b26a5c53c28

The patch I've posted contains a couple corrections and comments. Sorry for being this slow; the cold isn't very beneficial for my concentration.

EDIT: The commit list below has nothing to do with my post; it seems that trac automatically appends it to whatever post is made first after the commits. Anyway, for everyone who is not at Davis: The git commits on this ticket are a sandbox for people merging git; the true work is being done in the hg patches. I'm very positive this one is going to be reviewed way before we move over to git.


New commits:

[changeset:8138949]Merge branch 'u/darij/ticket/15300' of trac.sagemath.org:sage into gregg-change
[changeset:9f8c4a1]merged with Anne
[changeset:529d73c]Merge branch 'u/bump/ticket/15300' of git://trac.sagemath.org/sage into ticket/15300
[changeset:9086aca]added spaces
[changeset:911906c]#15300: Implement Weyl and Clifford algebras.
[changeset:2033f23]trying out git (pyflakes corrections)
Last edited 6 years ago by darij (previous) (diff)

comment:11 Changed 6 years ago by tscrim

  • Branch changed from u/gmoose05/ticket/15300 to public/algebras/weyl_clifford-15300
  • Commit changed from 8138949135606946e05c9dbf13a31b26a5c53c28 to c2f2fef272d3ed188b41a5920e57551c7cc9e5e0

New commits:

c2f2fefMerge branch 'master' into public/algebras/weyl_clifford-15300

comment:12 Changed 6 years ago by git

  • Commit changed from c2f2fef272d3ed188b41a5920e57551c7cc9e5e0 to 802459a51d26d7d3be14344f3e806446f4622117

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

802459atrac #15300: some remarks

comment:13 Changed 6 years ago by tscrim

  • Keywords days54 added

comment:14 Changed 6 years ago by git

  • Commit changed from 802459a51d26d7d3be14344f3e806446f4622117 to dce70bbeaba4c8fcf1ae17b904bd093e7584b5be

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

dce70bbFixes to Clifford algebras and expanded to have a functor method lift_morphism()
728019aMerge branch 'master' into public/algebras/weyl_clifford-15300

comment:15 Changed 6 years ago by git

  • Commit changed from dce70bbeaba4c8fcf1ae17b904bd093e7584b5be to 6b69822aedae5c6326dd9b247eb9c84cf1e07775

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

6b69822More docstring tweaks to Clifford algebra.
f759608Added lift_isometry method.

comment:16 follow-up: Changed 6 years ago by darij

Is there an established class for bilinear forms (not necessarily symmetric!) on free modules? I'd need one to get anywhere towards the Clifford-exterior iso.

The scalar function as it stands is rather useless, since on the exterior algebra it just returns the product of the constant coefficients of self and other. What should be made (I can do that) is the lift of a bilinear (not quadratic) form on V to the exterior algebra of V (using the Gram matrix). But that requires bilinear forms, too, so I'd love to hear whether they exist before doing any changes.

comment:17 Changed 6 years ago by git

  • Commit changed from 6b69822aedae5c6326dd9b247eb9c84cf1e07775 to 760de0bd03f0b251215ecdaf981759fb37362aeb

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

760de0bsome doc fixes

comment:18 in reply to: ↑ 16 Changed 6 years ago by tscrim

Replying to darij:

Is there an established class for bilinear forms (not necessarily symmetric!) on free modules? I'd need one to get anywhere towards the Clifford-exterior iso.

I don't think so. I think this is usually worked (hacked) around using dedicated methods.

The scalar function as it stands is rather useless, since on the exterior algebra it just returns the product of the constant coefficients of self and other. What should be made (I can do that) is the lift of a bilinear (not quadratic) form on V to the exterior algebra of V (using the Gram matrix). But that requires bilinear forms, too, so I'd love to hear whether they exist before doing any changes.

I'd just have a function Element.scalar(other) (or some other name) which projects down self and other to the exterior algebra and does the computation there via some (predefined) scalar() method.

comment:19 Changed 6 years ago by darij

Do you think it makes sense to add a BilinearForm class in analogy to QuadraticForm, or should I just use matrices to represent bilinear forms?

comment:20 Changed 6 years ago by nthiery

It depends what feature about bilinear forms you need for now. If it's just about computing it on some elements, I would stick for now with implementing appropriate "scalar" methods. Granted, it's a bit rudimentary. In the long run we want to have proper multivariate morphisms, with support from the coercion model. See #8900 and http://trac.sagemath.org/wiki/CategoriesRoadMap.

Cheers,

Nicolas

comment:21 follow-up: Changed 6 years ago by darij

What I want is to change the WeylAlgebra class to depend upon a space with a bilinear form, not on a polynomial ring. So the bilinear form will be a parameter. Still OK if it is a matrix or should I rather have an extra class?

comment:22 in reply to: ↑ 21 Changed 6 years ago by tscrim

Replying to darij:

What I want is to change the WeylAlgebra class to depend upon a space with a bilinear form, not on a polynomial ring. So the bilinear form will be a parameter. Still OK if it is a matrix or should I rather have an extra class?

I think a matrix would be best for now (although I would like to keep the polynomial ring version).

Thanks,
Travis

comment:23 Changed 6 years ago by darij

Will be a matrix then.

Yeah, I'm not going to deprecate your Weyl algebra; I *might* end up renaming it, though. Thing is, the Weyl algebra of an antisymmetric bilinear form is the most correct analogue of the Clifford algebra known to me (there might be better ones, though) -- far closer than the Weyl algebra of a polynomial ring (which is just the Weyl algebra of the usual antisymmetric form which is

0 1
-1 0

as a block matrix.

comment:24 Changed 6 years ago by tscrim

I'm okay with renaming the class, but I'd like to keep the global entry point the same. In other words, I'd like to create it via WeylAlgebra(QQ, 4), where the absence of the bilinear form says to use the polynomial representation, or perhaps with a keyword such as polynomial=True. Thanks.

Last edited 6 years ago by tscrim (previous) (diff)

comment:25 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:26 Changed 6 years ago by git

  • Commit changed from 760de0bd03f0b251215ecdaf981759fb37362aeb to e9902b97ed9281ad86ac4da7053b7821f6f07072

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

e9902b9Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:27 Changed 6 years ago by darij

There is a stupid __repr__ bug I've no idea how to fix.

sage: A = CliffordAlgebra(QuadraticForm(QQ, 3, [1,0,-1,3,-4,5]))
sage: A.basis()
Finite family {(0, 1): e0*e1, (1, 2): ee2, (0,): e0, (1,): e1, (0, 1, 2): e0*ee2, (2,): e2, (): 1, (0, 2): e0*e2}

See the ee2? It's an e1*e2, which the __repr__ routine seems to simplify to ee2 because 1* can be omitted, right? One way to deal with it would be to not use the multiplication signs; what do you think about that?

(Also, the doctests of lift_isometry are wrong -- could you compute them by hand and re-insert them? Thank you.)

EDIT: Oh, I see, the bug is in repr_from_monomials of weyl_algebra.py, not in some big free-module module.

Last edited 6 years ago by darij (previous) (diff)

comment:28 Changed 6 years ago by git

  • Commit changed from e9902b97ed9281ad86ac4da7053b7821f6f07072 to ba596fa77614533bbd1e6458ca397860dc85a7cb

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

c288a0cMerge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
015ce74Fix the repr.
ba596faFixed doctests in clifford_algebra.py.

comment:29 Changed 6 years ago by git

  • Commit changed from ba596fa77614533bbd1e6458ca397860dc85a7cb to dad0bcee526d94fee706fc53f1f2231cd3cda8f2

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

adc2fb1rename currently existing Weyl algebra classes, so as to later introduce something more general
dad0bcereview of repr_from_monomials

comment:30 Changed 6 years ago by git

  • Commit changed from dad0bcee526d94fee706fc53f1f2231cd3cda8f2 to 510913597592ed16dda3d8fb8faf1491222ae2c0

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

8749f21Added homology to exterior algebras.
6909a23Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
5109135Fixed doctests.

comment:31 Changed 6 years ago by git

  • Commit changed from 510913597592ed16dda3d8fb8faf1491222ae2c0 to 9bdf752a5cb49a3165b05536f190202ab9479c1b

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

9bdf752various improvements to clifford_algebra.py

comment:32 Changed 6 years ago by git

  • Commit changed from 9bdf752a5cb49a3165b05536f190202ab9479c1b to 9f5bb9766dc933ab23739fb7723ecf50fc684966

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

9f5bb97fix merge

comment:33 Changed 6 years ago by git

  • Commit changed from 9f5bb9766dc933ab23739fb7723ecf50fc684966 to ab37f83b6166add1ad61b8aa3e7a9ecee2b77a2d

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

ab37f83tuple(S) for S a set doesn't always return the increasing list

comment:34 Changed 6 years ago by git

  • Commit changed from ab37f83b6166add1ad61b8aa3e7a9ecee2b77a2d to a2354c64c0a288f2a3be35b0c7f655f10db60d4f

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

a2354c6minor edits

comment:35 Changed 6 years ago by git

  • Commit changed from a2354c64c0a288f2a3be35b0c7f655f10db60d4f to 8914cccac3d21077356686a84124041af82385b4

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

8914cccfurther clifford edits

comment:36 Changed 6 years ago by darij

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:

8914cccfurther clifford edits

comment:37 Changed 6 years ago by git

  • Commit changed from 8914cccac3d21077356686a84124041af82385b4 to 2a4ca79c189b0d5f776dbe980406a531cea79a3f

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

37f6cbfAdded coboundary operator.
2a4ca79Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:38 Changed 6 years ago by tscrim

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.

comment:39 Changed 6 years ago by darij

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

comment:40 Changed 6 years ago by darij

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.

comment:41 Changed 6 years ago by tscrim

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.

comment:42 Changed 6 years ago by tscrim

  • Dependencies set to #16037

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.

comment:43 Changed 6 years ago by git

  • Commit changed from 2a4ca79c189b0d5f776dbe980406a531cea79a3f to c470f1c2f65a95c0b5464279ffe6d41c3eeed0bd

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

4665988update dot2tex to latest dev version
702c72bform valid keys for dot2tex
e8abf26fix more doctest failures
289c212pointless bikeshedding of tarball name
0c5b4f8pyparsing is deprecating itself
ad62d43delete previous dot2tex directory if it exists
f6e95b4Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
e5cde4cSome fixes for doctests.
44ae929Hash function for families.
c470f1cMerge branch 'public/combinat/hash_family-16037' into public/algebras/weyl_clifford-15300

comment:44 Changed 6 years ago by tscrim

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

comment:45 Changed 6 years ago by darij

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.

comment:46 Changed 6 years ago by tscrim

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.

comment:47 Changed 6 years ago by git

  • Commit changed from c470f1c2f65a95c0b5464279ffe6d41c3eeed0bd to a1628e2d1a83460b7e2aa09664265afd5f847730

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

66fc007Some fixes for doctests.
c2f851bMerge branch 'public/combinat/hash_family-16037' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
2c5afd8More documentation and extended functorial-ness of exterior algebras.
a1628e2Documentation fixes.

comment:48 Changed 6 years ago by tscrim

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

comment:49 Changed 6 years ago by darij

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

comment:50 Changed 6 years ago by git

  • Commit changed from a1628e2d1a83460b7e2aa09664265afd5f847730 to a6a7206f3de8240b9783b8464c55f1ccb1d6cb4b

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

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

comment:51 Changed 6 years ago by tscrim

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

comment:52 follow-up: Changed 6 years ago by jhpalmieri

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.

comment:53 in reply to: ↑ 52 ; follow-up: Changed 6 years ago by tscrim

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?

Last edited 6 years ago by tscrim (previous) (diff)

comment:54 Changed 6 years ago by darij

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.

comment:55 Changed 6 years ago by tscrim

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

comment:56 Changed 6 years ago by darij

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.

comment:57 Changed 6 years ago by tscrim

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

comment:58 in reply to: ↑ 53 ; follow-up: Changed 6 years ago by jhpalmieri

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.

comment:59 in reply to: ↑ 58 Changed 6 years ago by tscrim

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.

comment:60 Changed 6 years ago by git

  • Commit changed from a6a7206f3de8240b9783b8464c55f1ccb1d6cb4b to 3c66a3f2610b466d6b350cebe6ed1e6ba9d10a22

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

3c66a3ffix coercion of zero coordinates

comment:61 Changed 6 years ago by git

  • Commit changed from 3c66a3f2610b466d6b350cebe6ed1e6ba9d10a22 to 52a13d99bd156488790c438e6a16d1e08abb703b

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

52a13d9correct typing in lift_morphism

comment:62 Changed 6 years ago by git

  • Commit changed from 52a13d99bd156488790c438e6a16d1e08abb703b to d8c17dc08dc5f51caed795eaf90fb3762aa5ab02

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

d8c17dc-1 useless line

comment:63 Changed 6 years ago by darij

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

comment:64 Changed 6 years ago by git

  • Commit changed from d8c17dc08dc5f51caed795eaf90fb3762aa5ab02 to 18b9529914faafb25d26bba0435ef06a9914b619

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

18b9529correct definition of coproduct

comment:65 Changed 6 years ago by darij

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

Last edited 6 years ago by darij (previous) (diff)

comment:66 Changed 6 years ago by darij

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

comment:67 follow-up: Changed 6 years ago by tscrim

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.

comment:68 Changed 6 years ago by darij

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?

comment:69 Changed 6 years ago by darij

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

comment:70 in reply to: ↑ 67 Changed 6 years ago by tscrim

Replying to tscrim:

... into combinat/combinat.py

We should probably have internal_product_on_basis reference Element.internal_product.

comment:71 Changed 6 years ago by git

  • Commit changed from 18b9529914faafb25d26bba0435ef06a9914b619 to 651d063bc8b31671621207fa47299311a13a5f5c

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

689bce2identity instead of equality for base rings
651d063some clarifications on interior product

comment:72 Changed 6 years ago by git

  • Commit changed from 651d063bc8b31671621207fa47299311a13a5f5c to de4cc8c2be64048a1f38fe7ce3b91985d62992ca

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

de4cc8canother try at sphinx

comment:73 Changed 6 years ago by darij

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 :/

Last edited 6 years ago by darij (previous) (diff)

comment:74 Changed 6 years ago by git

  • Commit changed from de4cc8c2be64048a1f38fe7ce3b91985d62992ca to 9e059dd4d8f8a78f08b5b8e9619d2ae71bff18bc

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

9e059ddmoved unshuffle iterator into sage/combinat/combinat.py

comment:75 Changed 6 years ago by git

  • Commit changed from 9e059dd4d8f8a78f08b5b8e9619d2ae71bff18bc to 0594f5534fa08591bd22a59f0f4fc751e15e54b6

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

0594f55meanwhile, review multiplication of exterior algebra

comment:76 Changed 6 years ago by darij

Also, an explanation of how exactly the s_coeff dictionary is being parsed would be nice (e.g. what happens if I set both its (1,2) and its (2,1) values?).

Last edited 6 years ago by darij (previous) (diff)

comment:77 Changed 6 years ago by tscrim

Sorry for the delays on this; been doing some math and construction. I'll add some doc to the interior product which will hopefully make everything clear. Same for the s_coeff.

I think it's better to do by identity. It's faster for UR base rings (or so I've been told and I'd be surprised if it wasn't), and if it's equal but not identical, I think we should change it to make sure its parent is identically the base ring.

Hope you feel better Darij.

comment:78 follow-up: Changed 6 years ago by darij

Thank you. As long as the identity check doesn't cause bugs (rather than just slowness) when the rings are non-identical but equal, it's all fine (and does make more sense than equality, probably). I'll come back to reviewing once s_coeff is documented.

What centers are you going to add? Exterior algebra or also the Clifford algebra? Regular center or supercenter or both? How are you planning to deal with the cases where the basis of the center is not part of the basis of the algebra?

comment:79 in reply to: ↑ 78 Changed 6 years ago by tscrim

Replying to darij:

What centers are you going to add? Exterior algebra or also the Clifford algebra? Regular center or supercenter or both? How are you planning to deal with the cases where the basis of the center is not part of the basis of the algebra?

Both Clifford and special case the exterior algebra, and I'm going to (try to do) both regular center and the supercenter. It reduces down to a linear algebra problem, and I was just going to return the elements which are a basis for the center (since there's currently no good framework for subalgebras).

comment:80 Changed 6 years ago by darij

Ah, very nice!

comment:81 Changed 6 years ago by git

  • Commit changed from 0594f5534fa08591bd22a59f0f4fc751e15e54b6 to a4aee8bf4a51175cf3b133239cc8e1f8a1f462e1

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

dee6404Merge branch 'develop' into public/algebras/weyl_clifford-15300
36cdf94Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
a4aee8bAdded methods for center and supercenter. Added doc Darij requested.

comment:82 Changed 6 years ago by tscrim

Centers, supercenters, and documentation added. Back to you Darij.

comment:83 Changed 6 years ago by git

  • Commit changed from a4aee8bf4a51175cf3b133239cc8e1f8a1f462e1 to e623a31127b4f5eb107dd4893dff8665cbe0ef12

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

e623a31Removed dangling print.

comment:84 Changed 6 years ago by git

  • Commit changed from e623a31127b4f5eb107dd4893dff8665cbe0ef12 to 61e2312010e3b0d1a526ef25dbc20c95d8a0c350

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

61e2312A smarter way to compute the center.

comment:85 Changed 6 years ago by darij

Thanks for the docs! I'll look into them (currently I'm recompiling Sage, for the third time within 2 days). Is it really your intention to denote the supercommutator by [x, y\}?

The Classification_of_Clifford_algebras#Pseudoscalar wikipedia link is misformatted.

comment:86 Changed 6 years ago by git

  • Commit changed from 61e2312010e3b0d1a526ef25dbc20c95d8a0c350 to d17dbb134af9631c68bfcd8c437eeadb7a924be1

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

c0e428dMerge branch 'develop' into public/algebras/weyl_clifford-15300
56a93c8Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
d17dbb1Fixed misformatted wikipedia link.

comment:87 Changed 6 years ago by tscrim

Yes, that is my intention. It's notation from my algebra teacher and it comes from a combo of the commutator and anticommutator notations.

I've also fixed the link formatting.

comment:88 Changed 6 years ago by git

  • Commit changed from d17dbb134af9631c68bfcd8c437eeadb7a924be1 to 52ca5ba6570237a3d205bef23afa3721dd4cc9e1

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

52ca5baFix doc in combinat/combinat.py, removed some deprecated code, and other misc cleanups nearby.

comment:89 Changed 6 years ago by git

  • Commit changed from 52ca5ba6570237a3d205bef23afa3721dd4cc9e1 to cbe4ebd5b4d9dbdeed49bba0789b62fbf7dd80a9

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

cbe4ebdAlso removed them from all.py.

comment:90 Changed 6 years ago by git

  • Commit changed from cbe4ebd5b4d9dbdeed49bba0789b62fbf7dd80a9 to e2fa004012f5b1e27c70f69595fba33e0a4bf8f8

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

e2fa004Last fixes for sphinx in combinat.py.

comment:91 Changed 6 years ago by git

  • Commit changed from e2fa004012f5b1e27c70f69595fba33e0a4bf8f8 to b96e811f98e3450c4729f28b346a73dd1d9621e0

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

b96e811catching up with CliffordAlgebra changes

comment:92 Changed 6 years ago by git

  • Commit changed from b96e811f98e3450c4729f28b346a73dd1d9621e0 to 266d36c4926a4e49b787ee3ffb57f9e3c93927a9

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

266d36cmore optimizations

comment:93 Changed 6 years ago by darij

While I'm not yet done with clifford_algebra.py, could you perhaps improve the doc of the expand_derivative method in weyl_algebras.py? It looks mysterious to me (and is it really supposed to change the dictionary d while iterating through it?). Thank you!

EDIT: Also, what do you think of renaming (super)center as (super)center_basis, for the off chance that Sage will eventually be expressive enough to define actual subalgebras?

Last edited 6 years ago by darij (previous) (diff)

comment:94 Changed 6 years ago by git

  • Commit changed from 266d36c4926a4e49b787ee3ffb57f9e3c93927a9 to 0956df62fba7d76a2ce44f71b696669dd5401808

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

b213890Merge branch 'develop' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
e475be8Added to doc of expand_derivative().
0956df6Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:95 Changed 6 years ago by git

  • Commit changed from 0956df62fba7d76a2ce44f71b696669dd5401808 to 63300420457d32e4c14359e07093546ca704647d

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

6330042Changed (super)center() to (super)center_basis().

comment:96 Changed 6 years ago by tscrim

I've added some more to the doc. Also I iterate over the items of d (which is a list created when the for loop is first called), so it's safe for me to do that iteration. I've also changed the (super)center() to (super)center_basis() since that will make it easier to deprecate these once subalgebras are properly implemented.

comment:97 Changed 6 years ago by git

  • Commit changed from 63300420457d32e4c14359e07093546ca704647d to 1f813301d36403c6e1f366063ff4b9c86d618546

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

1f81330manual merge with 6.2.beta8

comment:98 Changed 6 years ago by git

  • Commit changed from 1f813301d36403c6e1f366063ff4b9c86d618546 to ade2b4ecbcf7d53d303e5dc2846d00f8719cac3f

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

fc6e190Merge branch 'develop' into public/algebras/weyl_clifford-15300
ade2b4eMerge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:99 Changed 6 years ago by git

  • Commit changed from ade2b4ecbcf7d53d303e5dc2846d00f8719cac3f to 3a069b118332dbf0e166dd678708b3c44505f4ee

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

897b405Merge branch 'public/algebras/weyl_clifford-15300' of git://trac.sagemath.org/sage into clifford
3a069b1lame improvements, getting tired way too quickly these days

comment:100 Changed 6 years ago by git

  • Commit changed from 3a069b118332dbf0e166dd678708b3c44505f4ee to 425fb7d0db5d8f3e4f5f6a2b64c3256fd8d8d8a6

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

425fb7dcorrect if ugly handling of border cases in complex constructors

comment:101 Changed 6 years ago by git

  • Commit changed from 425fb7d0db5d8f3e4f5f6a2b64c3256fd8d8d8a6 to c00cda194f417554a3a9196b4b3cfb0be51b5670

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

c00cda1finishing clifford_algebra.py review

comment:102 Changed 6 years ago by git

  • Commit changed from c00cda194f417554a3a9196b4b3cfb0be51b5670 to 15a36c6b3755d7221f85454a118fe824ddb187b1

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

15a36c6fix my own abuse of degree_on_basis and add warning

comment:103 Changed 6 years ago by git

  • Commit changed from 15a36c6b3755d7221f85454a118fe824ddb187b1 to e46a8908ecfbbf76cef893b5b5399a1f2f354450

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

e46a890Made "lazy" basis for Clifford (and descent) algebras.

comment:104 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:105 follow-up: Changed 6 years ago by darij

Thanks for catching my stupid mistake in the supercommutator doctests!

The reason why I said "exactly one" rather than "only one" is this:

sage: w = E.boundary({(0,1): 0, (1,2): 0, (2,0): 0})
sage: w2 = E.boundary({(0,1): 0, (1,2): 0})
sage: w == w2
False

Is this an issue? Is w2 still functional?

Sorry for my renewed slowdown; the good news is that semester isn't going to go on forever.

comment:106 Changed 6 years ago by git

  • Commit changed from e46a8908ecfbbf76cef893b5b5399a1f2f354450 to a24b97622cc9eda05688b1a232c8d16dbea3018e

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

c9bea41Merge branch 'public/algebras/weyl_clifford-15300' of git://trac.sagemath.org/sage into cliffnew
a24b976doc improvements on combinat/subset.py (response to e46a89)

comment:107 in reply to: ↑ 105 Changed 6 years ago by tscrim

Replying to darij:

The reason why I said "exactly one" rather than "only one" is this:

sage: w = E.boundary({(0,1): 0, (1,2): 0, (2,0): 0})
sage: w2 = E.boundary({(0,1): 0, (1,2): 0})
sage: w == w2
False

Is this an issue? Is w2 still functional?

It's more of an abuse and lack of good normalization (i.e. the 0's should be removed from UR supercall).

comment:108 Changed 6 years ago by git

  • Commit changed from a24b97622cc9eda05688b1a232c8d16dbea3018e to fdd8b2367bf47519a2cca0dbe616a42362c3ed00

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

ae390beMerge branch 'develop' into public/algebras/weyl_clifford-15300
7edf97cMerge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
04ccfd0Merge branch 'develop' into public/algebras/weyl_clifford-15300
fdd8b23Fixed normalization of (co)boundary s_coeff w/ 0 terms

comment:109 Changed 6 years ago by tscrim

Fixed:

sage: E.<x,y,z> = ExteriorAlgebra(QQ)
sage: w = E.boundary({(0,1): 0, (1,2): 0, (2,0): 0})
sage: w2 = E.boundary({(0,1): 0, (1,2): 0})
sage: w == w2
True

comment:110 Changed 5 years ago by git

  • Commit changed from fdd8b2367bf47519a2cca0dbe616a42362c3ed00 to f2a269f2e7de6fabf94a9dd947b530cfcbdfc8df

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

54aa513Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300
622a501Changing SubsetsSorted to work with new Subsets version.
f2a269fFixed contianment of SubsetsSorted.

comment:111 Changed 5 years ago by git

  • Commit changed from f2a269f2e7de6fabf94a9dd947b530cfcbdfc8df to 4556bd8a9d13960361ff23745bf4c6dd738c534a

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

4556bd8Merge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:112 Changed 5 years ago by darij

Red again. (Not that I have time to review it these days, but I just noticed when trying to move the branches over to a new install.)

comment:113 Changed 5 years ago by git

  • Commit changed from 4556bd8a9d13960361ff23745bf4c6dd738c534a to cbb0facc515ae6738351ef41d751da0a3042f74f

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

cbb0facMerge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:114 Changed 5 years ago by tscrim

Hmmm...I didn't get any merge conflicts...

comment:115 Changed 5 years ago by darij

Ah, thanks. I think git's automerge is smarter than what the trac server does...

Last edited 5 years ago by darij (previous) (diff)

comment:116 Changed 5 years ago by git

  • Commit changed from cbb0facc515ae6738351ef41d751da0a3042f74f to 958de6c41b3d8bd27266078493f0f5e49bd80657

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

958de6cmanual merge, let's see if correct

comment:117 Changed 5 years ago by darij

Sorry, I think my merge is wrong; or why am I getting this:

Traceback (most recent call last):
  File "/home/darij/sage-6.3.beta6/src/bin/sage-runtests", line 87, in <module>
    err = DC.run()
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/doctest/control.py", line 904, in run
    self.run_doctests()
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/doctest/control.py", line 674, in run_doctests
    self.dispatcher = DocTestDispatcher(self)
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1335, in __init__
    init_sage()
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 95, in init_sage
    import sage.all_cmdline
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/all_cmdline.py", line 18, in <module>
    from sage.all import *
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/all.py", line 134, in <module>
    from sage.combinat.all   import *
  File "/home/darij/sage-6.3.beta6/local/lib/python2.7/site-packages/sage/combinat/all.py", line 1, in <module>
    from combinat import bell_number, catalan_number, euler_number, fibonacci, \
ImportError: cannot import name permutations_iterator

Also, do you happen to remember what parts I have reviewed? I reviewed clifford_algebra.py once, but I'm not sure whether it was the latest version.

Last edited 5 years ago by darij (previous) (diff)

comment:118 Changed 5 years ago by git

  • Commit changed from 958de6c41b3d8bd27266078493f0f5e49bd80657 to 14530b43ae565bc43f10b4bfe12a26e8d29f4bab

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

14530b4fix doctest failure

comment:119 Changed 5 years ago by darij

OK, fixed (this was a stupid conflict from one of the previous merges).

comment:120 Changed 5 years ago by git

  • Commit changed from 14530b43ae565bc43f10b4bfe12a26e8d29f4bab to 41662391d4212f56f1066f069091578491a936bf

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

4166239whitespace ffs

comment:121 Changed 5 years ago by tscrim

IIRC, you've reviewed the current version of clifford_algebra.py and SubsetsSorted. You had mentioned you wanted to do a bit of a rewrite of WeylAlgebra to include more general definitions, but IDK if you reviewed the current implementation.

comment:122 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:123 follow-up: Changed 5 years ago by darij

Why does the branch look like it nukes permutation.py? http://git.sagemath.org/sage.git/diff/?id=d3aba3ff1bcfb9acc035013fb7f794de57c8f09e

comment:124 Changed 5 years ago by git

  • Commit changed from 41662391d4212f56f1066f069091578491a936bf to b26d10cb8295d22122067048b648f2ab548578bf

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

b26d10cMerge branch 'public/algebras/weyl_clifford-15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford-15300

comment:125 in reply to: ↑ 123 Changed 5 years ago by tscrim

Replying to darij:

Why does the branch look like it nukes permutation.py? http://git.sagemath.org/sage.git/diff/?id=d3aba3ff1bcfb9acc035013fb7f794de57c8f09e

It's a trac issue (likely due to a merge (to be) done permutation.py). Here's what I got when I pulled the branch:

From trac.sagemath.org:sage
 * branch            public/algebras/weyl_clifford-15300 -> FETCH_HEAD
Auto-merging src/sage/combinat/permutation.py
Merge made by the 'recursive' strategy.
 src/doc/en/reference/algebras/index.rst |    4 +
 src/sage/algebras/all.py                |    4 +
 src/sage/algebras/clifford_algebra.py   | 2575 +++++++++++++++++++++++++++++++
 src/sage/algebras/weyl_algebra.py       |  548 +++++++
 src/sage/combinat/all.py                |    4 +-
 src/sage/combinat/combinat.py           |  202 ++-
 src/sage/combinat/descent_algebra.py    |   11 +-
 src/sage/combinat/permutation.py        |    8 +-
 src/sage/combinat/subset.py             |  201 ++-
 9 files changed, 3456 insertions(+), 101 deletions(-)
 create mode 100644 src/sage/algebras/clifford_algebra.py
 create mode 100644 src/sage/algebras/weyl_algebra.py

I've push a rebased branch which takes care of that. Are you getting back to finishing the review here?

comment:126 follow-up: Changed 5 years ago by darij

I can't say that yet, but I guess I'll know by the end of this week. I'm just finished with procrastinated work I was to do this summer...

comment:127 in reply to: ↑ 126 Changed 5 years ago by tscrim

Replying to darij:

I can't say that yet, but I guess I'll know by the end of this week. I'm just finished with procrastinated work I was to do this summer...

I know that feeling. Don't worry too much as there isn't a big rush on this. Also I might have #17096 ready before this (most of the code just needs to be factored out of #15484 and graded algebras).

comment:128 Changed 5 years ago by darij

Thanks for the merge, by the way!

So am I seeing it right that the purpose of expand_derivative is to commute a (monomial) differential operator past a polynomial?

comment:129 Changed 5 years ago by git

  • Commit changed from b26d10cb8295d22122067048b648f2ab548578bf to 130d1498f68ae297e2298abc13265133f39eca8f

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

130d149update to new develop

comment:130 Changed 5 years ago by darij

Sorry, I fear I won't have the time for this until November :(

Please ask on sage-devel for someone to review the rest of weyl_algebra.py (I have reviewed repr_from_monomials, though I can't guarantee it was the newest version). The general Weyl algebra can then go into a separate ticket, although it might require reverse-incompatible changes to the differential one (I hope it won't).

PS. Why does __monomial work on a DifferentialAlgebraElement? in the sourcecode but not in the Sage console? Is this some cython hackery?

Last edited 5 years ago by darij (previous) (diff)

comment:131 Changed 5 years ago by jhpalmieri

I might be able to finish the review, but I'm not sure. Meanwhile, a few questions and comments:

  • should there be a weyl_algebra (or similarly named) method for polynomial rings, so this could be found by tab completion once you had a polynomial ring R?
  • should it be possible to do W.<dx0, dx1, ...> = DifferentialWeylAlgebra(R)?

Some links are broken in clifford_algebra.py:

  • src/sage/algebras/clifford_algebra.py

    diff --git a/src/sage/algebras/clifford_algebra.py b/src/sage/algebras/clifford_algebra.py
    index 7670255..15a305d 100644
    a b class CliffordAlgebra(CombinatorialFreeModule): 
    899899
    900900        REFERENCES:
    901901
    902         - :wikipedia:`Classification_of_Clifford_algebras#Pseudoscalar`
     902        - :wikipedia:`Classification_of_Clifford_algebras#Unit_pseudoscalar`
    903903        """
    904904        d = self._quadratic_form.dim()
    905905        return self.element_class(self, {tuple(range(d)): self.base_ring().one()})
    class CliffordAlgebra(CombinatorialFreeModule): 
    11131113
    11141114        .. SEEALSO::
    11151115
    1116             :meth:`supercenter`,
     1116            :meth:`supercenter_basis`,
    11171117            http://math.stackexchange.com/questions/129183/center-of-clifford-algebra-depending-on-the-parity-of-d
    11181118
    11191119        .. TODO::
    class CliffordAlgebra(CombinatorialFreeModule): 
    12031203
    12041204        .. SEEALSO::
    12051205
    1206             :meth:`center`,
     1206            :meth:`center_basis`,
    12071207            http://math.stackexchange.com/questions/129183/center-of-clifford-algebra-depending-on-the-parity-of-d
    12081208
    12091209        .. TODO::

comment:132 Changed 5 years ago by jhpalmieri

A few more comments: the documentation for expand_derivative could use a little work. The sum in the displayed math is over which monomials? What is c_{\alpha}(X)?

I think you could also add more to the documentation for the DifferentialWeylAlgebra class: all you really have now is a link to a wikipedia article. At least mention the generators and relations. Your documentation for CliffordAlgebra is very nice, in contrast.

I'm wondering about the generators for a Weyl algebra. I think I expect gen (and gens and ngens) to return the algebra generators, so if we start with a polynomial algebra on one generator x, we should get both x and dx, not just dx. I can see that it would be useful to have a method returning just dx as a generator, but maybe that method should be called something else. Alternatively, the gen method could just return dx, but it should be clearly documented, explaining that it doesn't return all of the algebra generators; to get those, you should do algebra_generators instead (which at the moment is available via tab-completion but is not implemented). The method ngens should be changed accordingly.

I guess you could be viewing the Weyl algebra as an algebra over the polynomial ring, but isn't it usual, if you have an algebra A over a ring R, to assume that R is central in A? The Weyl algebra is an iterated Ore extension over the polynomial ring on n generators, adding in one dx at a time, but even so, the first two places I look (Wikipedia, and McConnell & Robson's Noncommutative Noetherian Rings) describe such a Weyl algebra as having 2n generators, the original polynomial generators and the dx's. So I would discourage your current use of gen, gens, and ngens.

comment:133 Changed 5 years ago by darij

Agreeing with jhpalmieri on the generators. In particular, ngens should give 2n as opposed to n (or else the generalization to arbitrary skew forms will have a non-integer number of generators). I am also highly against non-central algebras being encoded as algebras.

As for expand_derivative, if I remember correctly it commutes a differential operator past a polynomial in the Weyl algebra; but I have never actually checked what it really does.

In other news, the failing doctests of the buildbot have nothing to do with this patch. When did Sage become so fickle?

Last edited 5 years ago by darij (previous) (diff)

comment:134 Changed 5 years ago by tscrim

I'm making these changes now (it's somewhat of a rewrite of the Weyl algebra, so it might take a day or so).

comment:135 Changed 5 years ago by git

  • Commit changed from 130d1498f68ae297e2298abc13265133f39eca8f to 165f943b828ca2a7f743139d101f9c9c913e96ac

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

d8d03f7Merge branch 'develop' into public/algebras/weyl_clifford-15300
165f943Rewrite Weyl algebra and reviewer suggestions added.

comment:136 Changed 5 years ago by tscrim

Okay, I've rewritten WeylAlgebra to be over the base ring of the polynomial ring and I've done the other reviewer changes. Back to you John.

The __monomial gets name mangled because of the 2 underscores by python. Sage hasn't become so fickle, so much as numerical imprecision/noise on different machines can be hard to foresee (or something like that). I think the tolerance for the noise has been slightly increased and the buildbots need updating, but IDK for sure right now.

comment:137 Changed 5 years ago by darij

I didn't take a real look at this, but there are some issues here:

+ - It's a simple ring that is not a matrix ring over a division ring.
+ - It's a non-commutative domain.
+ - For `n = `, it's a quotient of the universal enveloping algebra of the
+ Heisenberg algebra.
+ - Has no finite-dimensional representations in characteristic zero.

The "simple" part holds when R is a field. The "non-commutative domain" works only if R is an integral domain. In the third line, what is n ? (I think it is always a quotient of U(Heisenberg_n).

comment:138 Changed 5 years ago by darij

Actually, the simplicity of the Weyl algebra requires R to be a field of characteristic 0. If R is a field of positive characteristic p, then the Weyl algebra acts on R[x]/(x^p), and the kernel of the action is a nonzero proper ideal of the Weyl algebra.

comment:139 Changed 5 years ago by git

  • Commit changed from 165f943b828ca2a7f743139d101f9c9c913e96ac to b47af6ae9f8dd1e6d870ec986f81fb6913d12e16

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

34c9b4cChanges from the reviewers.
b47af6aA minor tweaking of the doc.

comment:140 Changed 5 years ago by tscrim

Fixed.

comment:141 follow-up: Changed 5 years ago by jhpalmieri

When do I need to do dx,dy,dz = sorted(W.differentials(), key=str) vs. dx,dy,dz = W.differentials()? There are examples of both sorts; is the second version ever safe? I've seen in my own testing that the variables method can return its elements in a random order, not necessarily alphabetical. Will the same happen with differentials or algebra_generators? It's nice that W.inject_variables() works well; maybe that should be advertised, or at least used in some examples.

When does _coerce_map_from_ return a map and not just True or False? Please add more explanation and an example.

A few small changes:

  • src/sage/algebras/weyl_algebra.py

    diff --git a/src/sage/algebras/weyl_algebra.py b/src/sage/algebras/weyl_algebra.py
    index 22300d9..8c256a0 100644
    a b class DifferentialWeylAlgebra(Algebra, UniqueRepresentation): 
    502502
    503503    - ``R`` -- a (polynomial) ring
    504504    - ``names`` -- (default: ``None``) if ``None`` and ``R`` is a
    505       polynomial ring, then consider the variable names corrspond to
     505      polynomial ring, then the variable names correspond to
    506506      those of ``R``; otherwise if ``names`` is specified, then ``R``
    507507      is the base ring
    508508
    class DifferentialWeylAlgebra(Algebra, UniqueRepresentation): 
    577577
    578578    def _element_constructor_(self, x):
    579579        """
    580         Construct and element of ``self`` from ``x``.
     580        Construct an element of ``self`` from ``x``.
    581581
    582582        EXAMPLES::
    583583

comment:142 in reply to: ↑ 141 ; follow-up: Changed 5 years ago by tscrim

Replying to jhpalmieri:

When do I need to do dx,dy,dz = sorted(W.differentials(), key=str) vs. dx,dy,dz = W.differentials()? There are examples of both sorts; is the second version ever safe? I've seen in my own testing that the variables method can return its elements in a random order, not necessarily alphabetical. Will the same happen with differentials or algebra_generators? It's nice that W.inject_variables() works well; maybe that should be advertised, or at least used in some examples.

The question is do we want to return a Family indexed by the variable names, which makes it act like a dict and have some specified order of output, or act like a list where the ordered of the output is the order of the input.

There's actually somewhat of mismatch and that algebra_generators should match the behavior of variables and differentials. The reason why inject_variables works is because of a specified order of gens, not algebra_generators (which would also be tweaked accordingly).

I'm bias towards making the outputs being indexed since it carries more information. However I do agree with adding examples demonstrating inject_variables and other similar constructions. Your thoughts?

When does _coerce_map_from_ return a map and not just True or False? Please add more explanation and an example.

This is the design of the function, and if it returns True, then coerce_map_from creates a map using _element_constructor_. There are times when it's easier/better-design to implement a custom morphism (like for a module with basis using module_morphism).

comment:143 in reply to: ↑ 142 ; follow-up: Changed 5 years ago by jhpalmieri

Replying to tscrim:

Replying to jhpalmieri:

When do I need to do dx,dy,dz = sorted(W.differentials(), key=str) vs. dx,dy,dz = W.differentials()? There are examples of both sorts; is the second version ever safe? I've seen in my own testing that the variables method can return its elements in a random order, not necessarily alphabetical. Will the same happen with differentials or algebra_generators? It's nice that W.inject_variables() works well; maybe that should be advertised, or at least used in some examples.

The question is do we want to return a Family indexed by the variable names, which makes it act like a dict and have some specified order of output, or act like a list where the ordered of the output is the order of the input.

I don't object to your design choice. My question was maybe more practical: is it ever safe to do dx,dy,dz=W.differentials(), or should they always be sorted? If it's not really safe, then there shouldn't be examples like that in the documentation.

I'm bias towards making the outputs being indexed since it carries more information. However I do agree with adding examples demonstrating inject_variables and other similar constructions. Your thoughts?

I think adding some examples using inject_variables would be useful. I think you could add them to the class-level docstring for DifferentialWeylAlgebra and/or to the weyl_algebra methods for polynomial rings (pointing out that the result of inject_variables is that the variables will now be in the Weyl algebra, not the polynomial ring).

When does _coerce_map_from_ return a map and not just True or False? Please add more explanation and an example.

This is the design of the function, and if it returns True, then coerce_map_from creates a map using _element_constructor_. There are times when it's easier/better-design to implement a custom morphism (like for a module with basis using module_morphism).

The docstring basically says, "if A, then return either X or Y, and otherwise return Z". A natural question is, when does it return X and when Y? Presumably it's not a coin flip. I'd like the documentation and the examples to explain this. Or do I never need to know this, things are just taken care of in the background? Then the documentation should say so.

comment:144 in reply to: ↑ 143 Changed 5 years ago by tscrim

Replying to jhpalmieri:

I don't object to your design choice. My question was maybe more practical: is it ever safe to do dx,dy,dz=W.differentials(), or should they always be sorted? If it's not really safe, then there shouldn't be examples like that in the documentation.

I'm starting to question my consistency in the design, so I will take another pass over things. Anyways, it's as safe as the ordering of d.keys() where d is a python dict...so not really. I'll make the necessary changes.

I think adding some examples using inject_variables would be useful. I think you could add them to the class-level docstring for DifferentialWeylAlgebra and/or to the weyl_algebra methods for polynomial rings (pointing out that the result of inject_variables is that the variables will now be in the Weyl algebra, not the polynomial ring).

Will do.

The docstring basically says, "if A, then return either X or Y, and otherwise return Z". A natural question is, when does it return X and when Y? Presumably it's not a coin flip. I'd like the documentation and the examples to explain this. Or do I never need to know this, things are just taken care of in the background? Then the documentation should say so.

As mentioned, this is the (abridged) specifications of the method, but I see your point. I will reword this.

Changes will be done in a little bit.

comment:145 follow-up: Changed 5 years ago by darij

Is this a standard situation in Sage that the order of the gens of an algebra/group/whatever cannot be trusted? This sounds like another reason to rewrite that method, and deserves its meta-ticket.

comment:146 in reply to: ↑ 145 Changed 5 years ago by tscrim

Replying to darij:

Is this a standard situation in Sage that the order of the gens of an algebra/group/whatever cannot be trusted? This sounds like another reason to rewrite that method, and deserves its meta-ticket.

It's not the order of gens (which by specs return a tuple), but instead that of algebra_generators (or similar) that returns a Family (by specs) which takes a dict as input. So the question becomes do we care about the ordering of the algebra generators? For me, the answer is no except for what's needed by inject_variables, but this is handled by gens.

Now it is possible to construct the data with a fixed input order by Family(index_set, function), and I wouldn't be too opposed to doing things this way. It gives a slight code smell to me, but it would probably be less surprising to a user...?

Thoughts?

comment:147 follow-up: Changed 5 years ago by darij

I think we should strive to have algebra_generators behave as gens should behave, as we are going to deprecate the latter in favor of the former one day. Or am I getting you wrong?

Last edited 5 years ago by darij (previous) (diff)

comment:148 in reply to: ↑ 147 Changed 5 years ago by tscrim

Replying to darij:

I think we should strive to have algebra_generators behave as gens should behave, as we are going to deprecate the latter in favor of the former one day. Or am I getting you wrong?

I think on that day, we should change the mechanism of inject_variables and the R.<x,y,z> syntax to retrieve the generators by their name. Also if we make algebra_generators return a Family which acts like a tuple, then we distance ourselves somewhat from what the infinite cases behave like-.

comment:149 Changed 5 years ago by jhpalmieri

I'm curious, where does it say that algebra_generators should return a Family?

I suppose in parallel with algebra_generators and gens, we could have variables and vars, returning a Family and a tuple respectively, and also differentials and diffs. Or something like that. Those names are not very evocative, so this does not seem ideal.

I feel that users will frequently want to do things like dx, dy, dz = W.differentials(), so we should have an obvious method which returns a sorted tuple. Maybe the method returning a family could be private (W._differentials()) or have a name like W.differentials_as_family()?

comment:150 Changed 5 years ago by git

  • Commit changed from b47af6ae9f8dd1e6d870ec986f81fb6913d12e16 to 53a9d7e6e93156fbf36fcfc0bf2c9b1109a1a679

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

53a9d7eFamilies return output based on order of variable names. Fixed coercion issue.

comment:151 Changed 5 years ago by tscrim

As per discussion, the result of variables and differentials returns sorted families based upon the ordering of the variable names. I also made it so that algebra_generators of the Clifford algebra returns a (similarly sorted) family. Furthermore I fixed the coercion (well...really a conversion) issue for modular images for Weyl algebras as was done for Clifford algebras.

comment:152 Changed 5 years ago by jhpalmieri

The warning in clifford_algebra.py has some typos:

The Clifford is not graded, but instead filtred.

should be

The Clifford algebra is not graded, but instead filtered.

Otherwise, I'm happy with it.

comment:153 Changed 5 years ago by git

  • Commit changed from 53a9d7e6e93156fbf36fcfc0bf2c9b1109a1a679 to 339b71d736c66aba83aa60899578558a0d182fca

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

339b71dFixed some typos.

comment:154 Changed 5 years ago by tscrim

  • Reviewers set to Darij Grinberg, John Palmieri

Fixed. So I believe everything has been reviewed at this point and means this is a positive review?

comment:155 Changed 5 years ago by jhpalmieri

  • Status changed from needs_review to positive_review

comment:156 Changed 5 years ago by tscrim

Thank you both!

comment:157 Changed 5 years ago by git

  • Commit changed from 339b71d736c66aba83aa60899578558a0d182fca to 86982750ec7fcf5a9a531702ee038dc26cadb401
  • Status changed from positive_review to needs_review

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

3ce3f6aMerge branch 'public/algebras/weyl_clifford-15300' of git://trac.sagemath.org/sage into clifford
8698275lifting bilinear forms onto exterior algebras

comment:158 Changed 5 years ago by darij

  • Summary changed from Weyl and Clifford Algebras to Clifford algebras and differential Weyl algebras

Thanks from me, too, John and Travis! Care to review one final piece of code? I have added the lifted bilinear form on the exterior algebra.

TODO list for further patches:

WEYL:

  • Weyl algebras in general. This will be mostly copypasting the structure of the Clifford algebra class.
  • Differential Weyl algebra as a particular case of a Weyl algebra (I think the matrix is the block matrix
    (0 -I
    I 0)
    here). Is this best achieved by having DifferentialWeylAlgebra? inherit from WeylAlgebra?, or better by coercions from one to the other? (I hope it's the former.)

CLIFFORD:

  • The canonical isomorphism between a Clifford algebra and an exterior algebra induced by a bilinear (! not quadratic !) form. This isomorphism, and its inverse, are particular cases of a common construction (Bourbaki's "Algèbre IX", §9, no. 2-3; Ricardo Baeza's "Quadratic Forms over Semilocal Rings", Lecture Notes in Mathematics 655, Springer 1978): If f and g are two bilinear forms on a module V, and if F and G are their corresponding quadratic forms (so F(x) = f(x, x) and G(x) = g(x, x)), then there is a canonical isomorphism from Cl(V, F) to Cl(V, F + G), which however depends on g and not just on G.
  • Use this Clifford-exterior isomorphism to define constant coefficients and scalar products on Clifford algebras. This will depend on a bilinear form.
  • Check if the scalar product on the Clifford algebra allows a faster way to compute the lifted bilinear form on the exterior algebra.

comment:159 Changed 5 years ago by vbraun

  • Status changed from needs_review to needs_work
sage -t --long --warn-long 38.2 src/sage/combinat/descent_algebra.py
git log**********************************************************************
File "src/sage/combinat/descent_algebra.py", line 292, in sage.combinat.descent_algebra.DescentAlgebra.D.to_B_basis
Failed example:
    map(B, D.basis()) # indirect doctest
Expected:
    [B[4],
     B[1, 3] - B[4],
     B[2, 2] - B[4],
     B[1, 1, 2] - B[1, 3] - B[2, 2] + B[4],
     B[3, 1] - B[4],
     B[1, 2, 1] - B[1, 3] - B[3, 1] + B[4],
     B[2, 1, 1] - B[2, 2] - B[3, 1] + B[4],
     B[1, 1, 1, 1] - B[1, 1, 2] - B[1, 2, 1] + B[1, 3]
      - B[2, 1, 1] + B[2, 2] + B[3, 1] - B[4]]
Got:
    [B[4],
     B[1, 3] - B[4],
     B[2, 2] - B[4],
     B[3, 1] - B[4],
     B[1, 1, 2] - B[1, 3] - B[2, 2] + B[4],
     B[1, 2, 1] - B[1, 3] - B[3, 1] + B[4],
     B[2, 1, 1] - B[2, 2] - B[3, 1] + B[4],
     B[1, 1, 1, 1] - B[1, 1, 2] - B[1, 2, 1] + B[1, 3] - B[2, 1, 1] + B[2, 2] + B[3, 1] - B[4]]
 **********************************************************************
1 item had failures:
   1 of   5 in sage.combinat.descent_algebra.DescentAlgebra.D.to_B_basis

comment:160 Changed 5 years ago by git

  • Commit changed from 86982750ec7fcf5a9a531702ee038dc26cadb401 to a002f4b47f23dea0b0dcd7b5dbf80a98af85b091

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

a002f4bSome tweaks to lifted_bilinear_form and fixed doctest.

comment:161 Changed 5 years ago by tscrim

  • Status changed from needs_work to needs_review

I made some tweaks to the lifted_bilinear_form. Most importantly I made it return a PoorManMap so the repr is nicer, and I changed the doc. I also fixed the doctest Volker noted.

comment:162 Changed 5 years ago by tscrim

Darij could you check my changes (and add a space to that last line in that descent_algebra.py doctest since all my cython files are recompiling currently)?

comment:163 Changed 5 years ago by darij

Done and done. I had to change the domain of the PoorManMap?, though, and I don't like the result very much.

comment:164 Changed 5 years ago by git

  • Commit changed from a002f4b47f23dea0b0dcd7b5dbf80a98af85b091 to ff27bdc5d87967d0e7fd5c1305cef4340db816c7

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

ff27bdcfurther fixes

comment:165 Changed 5 years ago by tscrim

  • Status changed from needs_review to positive_review

Ah yea. Duh. Thanks.

comment:166 Changed 5 years ago by vbraun

  • Branch changed from public/algebras/weyl_clifford-15300 to ff27bdc5d87967d0e7fd5c1305cef4340db816c7
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.