Opened 9 years ago
Closed 8 years ago
#15300 closed enhancement (fixed)
Clifford algebras and differential Weyl algebras
Reported by:  tscrim  Owned by:  tscrim 

Priority:  major  Milestone:  sage6.4 
Component:  algebra  Keywords:  days54 
Cc:  darij, sagecombinat  Merged in:  
Authors:  Travis Scrimshaw  Reviewers:  Darij Grinberg, John Palmieri 
Report Upstream:  N/A  Work issues:  
Branch:  ff27bdc (Commits, GitHub, GitLab)  Commit:  ff27bdc5d87967d0e7fd5c1305cef4340db816c7 
Dependencies:  #16037  Stopgaps: 
Description (last modified by )
Initial implementations of Weyl and Clifford algebras.
Attachments (2)
Change History (168)
comment:1 Changed 9 years ago by
 Status changed from new to needs_review
comment:2 Changed 9 years ago by
 Cc darij sagecombinat added
Changed 9 years ago by
comment:3 Changed 9 years ago by
 Branch set to u/mguaypaq/weylclifford
 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 9 years ago by
 Branch changed from u/mguaypaq/weylclifford to u/bump/ticket/15300
comment:5 Changed 9 years ago by
 Description modified (diff)
 Modified changed from 11/05/13 22:56:47 to 11/05/13 22:56:47
comment:6 Changed 9 years ago by
 Branch changed from u/bump/ticket/15300 to u/aschilling/ticket/15300
 Commit set to e3ff430ec720208e5f3635c28ef9f707b2c362f1
comment:7 Changed 9 years ago by
 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 9 years ago by
 Description modified (diff)
comment:9 Changed 9 years ago by
 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 9 years ago by
comment:10 Changed 9 years ago by
 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 greggchange 
[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) 
comment:11 Changed 9 years ago by
 Branch changed from u/gmoose05/ticket/15300 to public/algebras/weyl_clifford15300
 Commit changed from 8138949135606946e05c9dbf13a31b26a5c53c28 to c2f2fef272d3ed188b41a5920e57551c7cc9e5e0
New commits:
c2f2fef  Merge branch 'master' into public/algebras/weyl_clifford15300 
comment:12 Changed 9 years ago by
 Commit changed from c2f2fef272d3ed188b41a5920e57551c7cc9e5e0 to 802459a51d26d7d3be14344f3e806446f4622117
comment:13 Changed 9 years ago by
 Keywords days54 added
comment:14 Changed 8 years ago by
 Commit changed from 802459a51d26d7d3be14344f3e806446f4622117 to dce70bbeaba4c8fcf1ae17b904bd093e7584b5be
comment:15 Changed 8 years ago by
 Commit changed from dce70bbeaba4c8fcf1ae17b904bd093e7584b5be to 6b69822aedae5c6326dd9b247eb9c84cf1e07775
comment:16 followup: ↓ 18 Changed 8 years ago by
Is there an established class for bilinear forms (not necessarily symmetric!) on free modules? I'd need one to get anywhere towards the Cliffordexterior 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 8 years ago by
 Commit changed from 6b69822aedae5c6326dd9b247eb9c84cf1e07775 to 760de0bd03f0b251215ecdaf981759fb37362aeb
Branch pushed to git repo; I updated commit sha1. New commits:
760de0b  some doc fixes 
comment:18 in reply to: ↑ 16 Changed 8 years ago by
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 Cliffordexterior 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 ofself
andother
. What should be made (I can do that) is the lift of a bilinear (not quadratic) form onV
to the exterior algebra ofV
(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 8 years ago by
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 8 years ago by
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 followup: ↓ 22 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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.
comment:25 Changed 8 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:26 Changed 8 years ago by
 Commit changed from 760de0bd03f0b251215ecdaf981759fb37362aeb to e9902b97ed9281ad86ac4da7053b7821f6f07072
Branch pushed to git repo; I updated commit sha1. New commits:
e9902b9  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

comment:27 Changed 8 years ago by
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 reinsert them? Thank you.)
EDIT: Oh, I see, the bug is in repr_from_monomials
of weyl_algebra.py
, not in some big freemodule module.
comment:28 Changed 8 years ago by
 Commit changed from e9902b97ed9281ad86ac4da7053b7821f6f07072 to ba596fa77614533bbd1e6458ca397860dc85a7cb
comment:29 Changed 8 years ago by
 Commit changed from ba596fa77614533bbd1e6458ca397860dc85a7cb to dad0bcee526d94fee706fc53f1f2231cd3cda8f2
comment:30 Changed 8 years ago by
 Commit changed from dad0bcee526d94fee706fc53f1f2231cd3cda8f2 to 510913597592ed16dda3d8fb8faf1491222ae2c0
comment:31 Changed 8 years ago by
 Commit changed from 510913597592ed16dda3d8fb8faf1491222ae2c0 to 9bdf752a5cb49a3165b05536f190202ab9479c1b
Branch pushed to git repo; I updated commit sha1. New commits:
9bdf752  various improvements to clifford_algebra.py

comment:32 Changed 8 years ago by
 Commit changed from 9bdf752a5cb49a3165b05536f190202ab9479c1b to 9f5bb9766dc933ab23739fb7723ecf50fc684966
Branch pushed to git repo; I updated commit sha1. New commits:
9f5bb97  fix merge

comment:33 Changed 8 years ago by
 Commit changed from 9f5bb9766dc933ab23739fb7723ecf50fc684966 to ab37f83b6166add1ad61b8aa3e7a9ecee2b77a2d
Branch pushed to git repo; I updated commit sha1. New commits:
ab37f83  tuple(S) for S a set doesn't always return the increasing list

comment:34 Changed 8 years ago by
 Commit changed from ab37f83b6166add1ad61b8aa3e7a9ecee2b77a2d to a2354c64c0a288f2a3be35b0c7f655f10db60d4f
Branch pushed to git repo; I updated commit sha1. New commits:
a2354c6  minor edits

comment:35 Changed 8 years ago by
 Commit changed from a2354c64c0a288f2a3be35b0c7f655f10db60d4f to 8914cccac3d21077356686a84124041af82385b4
Branch pushed to git repo; I updated commit sha1. New commits:
8914ccc  further clifford edits

comment:36 Changed 8 years ago by
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

comment:37 Changed 8 years ago by
 Commit changed from 8914cccac3d21077356686a84124041af82385b4 to 2a4ca79c189b0d5f776dbe980406a531cea79a3f
comment:38 Changed 8 years ago by
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 8 years ago by
Yes, but wouldn't that method require passing it a quadratic form? Or am I confusing it with __init__
?
comment:40 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
 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 8 years ago by
 Commit changed from 2a4ca79c189b0d5f776dbe980406a531cea79a3f to c470f1c2f65a95c0b5464279ffe6d41c3eeed0bd
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_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

e5cde4c  Some fixes for doctests.

44ae929  Hash function for families.

c470f1c  Merge branch 'public/combinat/hash_family16037' into public/algebras/weyl_clifford15300

comment:44 Changed 8 years ago by
Ack, #16026 somehow as gotten in there. I'll fix it later.
comment:45 Changed 8 years ago by
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 8 years ago by
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 functorlike, and I should get that done tonight.
comment:47 Changed 8 years ago by
 Commit changed from c470f1c2f65a95c0b5464279ffe6d41c3eeed0bd to a1628e2d1a83460b7e2aa09664265afd5f847730
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_family16037' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

2c5afd8  More documentation and extended functorialness of exterior algebras.

a1628e2  Documentation fixes.

comment:48 Changed 8 years ago by
Okay, fixed. I'm also done making changes.
comment:49 Changed 8 years ago by
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 8 years ago by
 Commit changed from a1628e2d1a83460b7e2aa09664265afd5f847730 to a6a7206f3de8240b9783b8464c55f1ccb1d6cb4b
comment:51 Changed 8 years ago by
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 followup: ↓ 53 Changed 8 years ago by
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 ; followup: ↓ 58 Changed 8 years ago by
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 ifrepr_lincomb
(defined insage.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?
comment:54 Changed 8 years ago by
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/centerofcliffordalgebradependingontheparityofdimv . I'd say let's wait until we have finitedimensional algebras in Sage (or do we already?), since the center is *not* usually spanned by a subset of the standard basis.
comment:55 Changed 8 years ago by
Arbitrary finite (dimensional) algebras given by multiplication tables were done in #12141.
comment:56 Changed 8 years ago by
Oh; what I meant was algebras without a prechosen 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 8 years ago by
I think a part of #15916 would be something to that effect.
comment:58 in reply to: ↑ 53 ; followup: ↓ 59 Changed 8 years ago by
Replying to tscrim:
Replying to jhpalmieri:
For the function
repr_from_monomials
, I wonder ifrepr_lincomb
(defined insage.misc.latex
) does kind of the same thing?As I recall,
repr_lincomb
doesn't have as nice of printing (IMO) asrepr_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 8 years ago by
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 generatorsx
)? 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 8 years ago by
 Commit changed from a6a7206f3de8240b9783b8464c55f1ccb1d6cb4b to 3c66a3f2610b466d6b350cebe6ed1e6ba9d10a22
Branch pushed to git repo; I updated commit sha1. New commits:
3c66a3f  fix coercion of zero coordinates

comment:61 Changed 8 years ago by
 Commit changed from 3c66a3f2610b466d6b350cebe6ed1e6ba9d10a22 to 52a13d99bd156488790c438e6a16d1e08abb703b
Branch pushed to git repo; I updated commit sha1. New commits:
52a13d9  correct typing in lift_morphism

comment:62 Changed 8 years ago by
 Commit changed from 52a13d99bd156488790c438e6a16d1e08abb703b to d8c17dc08dc5f51caed795eaf90fb3762aa5ab02
Branch pushed to git repo; I updated commit sha1. New commits:
d8c17dc  1 useless line

comment:63 Changed 8 years ago by
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 8 years ago by
 Commit changed from d8c17dc08dc5f51caed795eaf90fb3762aa5ab02 to 18b9529914faafb25d26bba0435ef06a9914b619
Branch pushed to git repo; I updated commit sha1. New commits:
18b9529  correct definition of coproduct

comment:65 Changed 8 years ago by
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 rightleft issue, and there is the question which is the multiplier and which is the multiplied).
comment:66 Changed 8 years ago by
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 followup: ↓ 70 Changed 8 years ago by
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 (lowlevel) 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 8 years ago by
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 8 years ago by
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 8 years ago by
Replying to tscrim:
... into
combinat/combinat.py
We should probably have internal_product_on_basis
reference Element.internal_product
.
comment:71 Changed 8 years ago by
 Commit changed from 18b9529914faafb25d26bba0435ef06a9914b619 to 651d063bc8b31671621207fa47299311a13a5f5c
comment:72 Changed 8 years ago by
 Commit changed from 651d063bc8b31671621207fa47299311a13a5f5c to de4cc8c2be64048a1f38fe7ce3b91985d62992ca
Branch pushed to git repo; I updated commit sha1. New commits:
de4cc8c  another try at sphinx

comment:73 Changed 8 years ago by
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 lefttoright, 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 :/
comment:74 Changed 8 years ago by
 Commit changed from de4cc8c2be64048a1f38fe7ce3b91985d62992ca to 9e059dd4d8f8a78f08b5b8e9619d2ae71bff18bc
Branch pushed to git repo; I updated commit sha1. New commits:
9e059dd  moved unshuffle iterator into sage/combinat/combinat.py

comment:75 Changed 8 years ago by
 Commit changed from 9e059dd4d8f8a78f08b5b8e9619d2ae71bff18bc to 0594f5534fa08591bd22a59f0f4fc751e15e54b6
Branch pushed to git repo; I updated commit sha1. New commits:
0594f55  meanwhile, review multiplication of exterior algebra

comment:76 Changed 8 years ago by
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?).
comment:77 Changed 8 years ago by
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 followup: ↓ 79 Changed 8 years ago by
Thank you. As long as the identity check doesn't cause bugs (rather than just slowness) when the rings are nonidentical 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 8 years ago by
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 8 years ago by
Ah, very nice!
comment:81 Changed 8 years ago by
 Commit changed from 0594f5534fa08591bd22a59f0f4fc751e15e54b6 to a4aee8bf4a51175cf3b133239cc8e1f8a1f462e1
Branch pushed to git repo; I updated commit sha1. New commits:
dee6404  Merge branch 'develop' into public/algebras/weyl_clifford15300

36cdf94  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

a4aee8b  Added methods for center and supercenter. Added doc Darij requested.

comment:82 Changed 8 years ago by
Centers, supercenters, and documentation added. Back to you Darij.
comment:83 Changed 8 years ago by
 Commit changed from a4aee8bf4a51175cf3b133239cc8e1f8a1f462e1 to e623a31127b4f5eb107dd4893dff8665cbe0ef12
Branch pushed to git repo; I updated commit sha1. New commits:
e623a31  Removed dangling print.

comment:84 Changed 8 years ago by
 Commit changed from e623a31127b4f5eb107dd4893dff8665cbe0ef12 to 61e2312010e3b0d1a526ef25dbc20c95d8a0c350
Branch pushed to git repo; I updated commit sha1. New commits:
61e2312  A smarter way to compute the center.

comment:85 Changed 8 years ago by
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 8 years ago by
 Commit changed from 61e2312010e3b0d1a526ef25dbc20c95d8a0c350 to d17dbb134af9631c68bfcd8c437eeadb7a924be1
Branch pushed to git repo; I updated commit sha1. New commits:
c0e428d  Merge branch 'develop' into public/algebras/weyl_clifford15300

56a93c8  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

d17dbb1  Fixed misformatted wikipedia link.

comment:87 Changed 8 years ago by
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 8 years ago by
 Commit changed from d17dbb134af9631c68bfcd8c437eeadb7a924be1 to 52ca5ba6570237a3d205bef23afa3721dd4cc9e1
Branch pushed to git repo; I updated commit sha1. New commits:
52ca5ba  Fix doc in combinat/combinat.py, removed some deprecated code, and other misc cleanups nearby.

comment:89 Changed 8 years ago by
 Commit changed from 52ca5ba6570237a3d205bef23afa3721dd4cc9e1 to cbe4ebd5b4d9dbdeed49bba0789b62fbf7dd80a9
Branch pushed to git repo; I updated commit sha1. New commits:
cbe4ebd  Also removed them from all.py.

comment:90 Changed 8 years ago by
 Commit changed from cbe4ebd5b4d9dbdeed49bba0789b62fbf7dd80a9 to e2fa004012f5b1e27c70f69595fba33e0a4bf8f8
Branch pushed to git repo; I updated commit sha1. New commits:
e2fa004  Last fixes for sphinx in combinat.py.

comment:91 Changed 8 years ago by
 Commit changed from e2fa004012f5b1e27c70f69595fba33e0a4bf8f8 to b96e811f98e3450c4729f28b346a73dd1d9621e0
Branch pushed to git repo; I updated commit sha1. New commits:
b96e811  catching up with CliffordAlgebra changes

comment:92 Changed 8 years ago by
 Commit changed from b96e811f98e3450c4729f28b346a73dd1d9621e0 to 266d36c4926a4e49b787ee3ffb57f9e3c93927a9
Branch pushed to git repo; I updated commit sha1. New commits:
266d36c  more optimizations

comment:93 Changed 8 years ago by
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?
comment:94 Changed 8 years ago by
 Commit changed from 266d36c4926a4e49b787ee3ffb57f9e3c93927a9 to 0956df62fba7d76a2ce44f71b696669dd5401808
Branch pushed to git repo; I updated commit sha1. New commits:
b213890  Merge branch 'develop' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

e475be8  Added to doc of expand_derivative().

0956df6  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

comment:95 Changed 8 years ago by
 Commit changed from 0956df62fba7d76a2ce44f71b696669dd5401808 to 63300420457d32e4c14359e07093546ca704647d
Branch pushed to git repo; I updated commit sha1. New commits:
6330042  Changed (super)center() to (super)center_basis().

comment:96 Changed 8 years ago by
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 8 years ago by
 Commit changed from 63300420457d32e4c14359e07093546ca704647d to 1f813301d36403c6e1f366063ff4b9c86d618546
Branch pushed to git repo; I updated commit sha1. New commits:
1f81330  manual merge with 6.2.beta8

comment:98 Changed 8 years ago by
 Commit changed from 1f813301d36403c6e1f366063ff4b9c86d618546 to ade2b4ecbcf7d53d303e5dc2846d00f8719cac3f
comment:99 Changed 8 years ago by
 Commit changed from ade2b4ecbcf7d53d303e5dc2846d00f8719cac3f to 3a069b118332dbf0e166dd678708b3c44505f4ee
comment:100 Changed 8 years ago by
 Commit changed from 3a069b118332dbf0e166dd678708b3c44505f4ee to 425fb7d0db5d8f3e4f5f6a2b64c3256fd8d8d8a6
Branch pushed to git repo; I updated commit sha1. New commits:
425fb7d  correct if ugly handling of border cases in complex constructors

comment:101 Changed 8 years ago by
 Commit changed from 425fb7d0db5d8f3e4f5f6a2b64c3256fd8d8d8a6 to c00cda194f417554a3a9196b4b3cfb0be51b5670
Branch pushed to git repo; I updated commit sha1. New commits:
c00cda1  finishing clifford_algebra.py review

comment:102 Changed 8 years ago by
 Commit changed from c00cda194f417554a3a9196b4b3cfb0be51b5670 to 15a36c6b3755d7221f85454a118fe824ddb187b1
Branch pushed to git repo; I updated commit sha1. New commits:
15a36c6  fix my own abuse of degree_on_basis and add warning

comment:103 Changed 8 years ago by
 Commit changed from 15a36c6b3755d7221f85454a118fe824ddb187b1 to e46a8908ecfbbf76cef893b5b5399a1f2f354450
Branch pushed to git repo; I updated commit sha1. New commits:
e46a890  Made "lazy" basis for Clifford (and descent) algebras.

comment:104 Changed 8 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:105 followup: ↓ 107 Changed 8 years ago by
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 8 years ago by
 Commit changed from e46a8908ecfbbf76cef893b5b5399a1f2f354450 to a24b97622cc9eda05688b1a232c8d16dbea3018e
comment:107 in reply to: ↑ 105 Changed 8 years ago by
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 FalseIs 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 8 years ago by
 Commit changed from a24b97622cc9eda05688b1a232c8d16dbea3018e to fdd8b2367bf47519a2cca0dbe616a42362c3ed00
Branch pushed to git repo; I updated commit sha1. New commits:
ae390be  Merge branch 'develop' into public/algebras/weyl_clifford15300

7edf97c  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

04ccfd0  Merge branch 'develop' into public/algebras/weyl_clifford15300

fdd8b23  Fixed normalization of (co)boundary s_coeff w/ 0 terms

comment:109 Changed 8 years ago by
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 8 years ago by
 Commit changed from fdd8b2367bf47519a2cca0dbe616a42362c3ed00 to f2a269f2e7de6fabf94a9dd947b530cfcbdfc8df
comment:111 Changed 8 years ago by
 Commit changed from f2a269f2e7de6fabf94a9dd947b530cfcbdfc8df to 4556bd8a9d13960361ff23745bf4c6dd738c534a
Branch pushed to git repo; I updated commit sha1. New commits:
4556bd8  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

comment:112 Changed 8 years ago by
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 8 years ago by
 Commit changed from 4556bd8a9d13960361ff23745bf4c6dd738c534a to cbb0facc515ae6738351ef41d751da0a3042f74f
Branch pushed to git repo; I updated commit sha1. New commits:
cbb0fac  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

comment:114 Changed 8 years ago by
Hmmm...I didn't get any merge conflicts...
comment:115 Changed 8 years ago by
Ah, thanks. I think git's automerge is smarter than what the trac server does...
comment:116 Changed 8 years ago by
 Commit changed from cbb0facc515ae6738351ef41d751da0a3042f74f to 958de6c41b3d8bd27266078493f0f5e49bd80657
Branch pushed to git repo; I updated commit sha1. New commits:
958de6c  manual merge, let's see if correct

comment:117 Changed 8 years ago by
Sorry, I think my merge is wrong; or why am I getting this:
Traceback (most recent call last): File "/home/darij/sage6.3.beta6/src/bin/sageruntests", line 87, in <module> err = DC.run() File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/doctest/control.py", line 904, in run self.run_doctests() File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/doctest/control.py", line 674, in run_doctests self.dispatcher = DocTestDispatcher(self) File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 1335, in __init__ init_sage() File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/doctest/forker.py", line 95, in init_sage import sage.all_cmdline File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/all_cmdline.py", line 18, in <module> from sage.all import * File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/sage/all.py", line 134, in <module> from sage.combinat.all import * File "/home/darij/sage6.3.beta6/local/lib/python2.7/sitepackages/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.
comment:118 Changed 8 years ago by
 Commit changed from 958de6c41b3d8bd27266078493f0f5e49bd80657 to 14530b43ae565bc43f10b4bfe12a26e8d29f4bab
Branch pushed to git repo; I updated commit sha1. New commits:
14530b4  fix doctest failure

comment:119 Changed 8 years ago by
OK, fixed (this was a stupid conflict from one of the previous merges).
comment:120 Changed 8 years ago by
 Commit changed from 14530b43ae565bc43f10b4bfe12a26e8d29f4bab to 41662391d4212f56f1066f069091578491a936bf
Branch pushed to git repo; I updated commit sha1. New commits:
4166239  whitespace ffs

comment:121 Changed 8 years ago by
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 8 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:123 followup: ↓ 125 Changed 8 years ago by
Why does the branch look like it nukes permutation.py? http://git.sagemath.org/sage.git/diff/?id=d3aba3ff1bcfb9acc035013fb7f794de57c8f09e
comment:124 Changed 8 years ago by
 Commit changed from 41662391d4212f56f1066f069091578491a936bf to b26d10cb8295d22122067048b648f2ab548578bf
Branch pushed to git repo; I updated commit sha1. New commits:
b26d10c  Merge branch 'public/algebras/weyl_clifford15300' of trac.sagemath.org:sage into public/algebras/weyl_clifford15300

comment:125 in reply to: ↑ 123 Changed 8 years ago by
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_clifford15300 > FETCH_HEAD Automerging 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 followup: ↓ 127 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
 Commit changed from b26d10cb8295d22122067048b648f2ab548578bf to 130d1498f68ae297e2298abc13265133f39eca8f
Branch pushed to git repo; I updated commit sha1. New commits:
130d149  update to new develop

comment:130 Changed 8 years ago by
Sorry, I fear I won't have the time for this until November :(
Please ask on sagedevel 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 reverseincompatible 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?
comment:131 Changed 8 years ago by
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 ringR
?  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): 899 899 900 900 REFERENCES: 901 901 902  :wikipedia:`Classification_of_Clifford_algebras# Pseudoscalar`902  :wikipedia:`Classification_of_Clifford_algebras#Unit_pseudoscalar` 903 903 """ 904 904 d = self._quadratic_form.dim() 905 905 return self.element_class(self, {tuple(range(d)): self.base_ring().one()}) … … class CliffordAlgebra(CombinatorialFreeModule): 1113 1113 1114 1114 .. SEEALSO:: 1115 1115 1116 :meth:`supercenter `,1116 :meth:`supercenter_basis`, 1117 1117 http://math.stackexchange.com/questions/129183/centerofcliffordalgebradependingontheparityofd 1118 1118 1119 1119 .. TODO:: … … class CliffordAlgebra(CombinatorialFreeModule): 1203 1203 1204 1204 .. SEEALSO:: 1205 1205 1206 :meth:`center `,1206 :meth:`center_basis`, 1207 1207 http://math.stackexchange.com/questions/129183/centerofcliffordalgebradependingontheparityofd 1208 1208 1209 1209 .. TODO::
comment:132 Changed 8 years ago by
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 tabcompletion 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 8 years ago by
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 noninteger number of generators). I am also highly against noncentral 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?
comment:134 Changed 8 years ago by
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 8 years ago by
 Commit changed from 130d1498f68ae297e2298abc13265133f39eca8f to 165f943b828ca2a7f743139d101f9c9c913e96ac
comment:136 Changed 8 years ago by
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 8 years ago by
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 noncommutative domain. +  For `n = `, it's a quotient of the universal enveloping algebra of the + Heisenberg algebra. +  Has no finitedimensional representations in characteristic zero.
The "simple" part holds when R is a field. The "noncommutative 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 8 years ago by
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 8 years ago by
 Commit changed from 165f943b828ca2a7f743139d101f9c9c913e96ac to b47af6ae9f8dd1e6d870ec986f81fb6913d12e16
comment:140 Changed 8 years ago by
Fixed.
comment:141 followup: ↓ 142 Changed 8 years ago by
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): 502 502 503 503  ``R``  a (polynomial) ring 504 504  ``names``  (default: ``None``) if ``None`` and ``R`` is a 505 polynomial ring, then consider the variable names corrspond to505 polynomial ring, then the variable names correspond to 506 506 those of ``R``; otherwise if ``names`` is specified, then ``R`` 507 507 is the base ring 508 508 … … class DifferentialWeylAlgebra(Algebra, UniqueRepresentation): 577 577 578 578 def _element_constructor_(self, x): 579 579 """ 580 Construct an delement of ``self`` from ``x``.580 Construct an element of ``self`` from ``x``. 581 581 582 582 EXAMPLES:: 583 583
comment:142 in reply to: ↑ 141 ; followup: ↓ 143 Changed 8 years ago by
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 thevariables
method can return its elements in a random order, not necessarily alphabetical. Will the same happen withdifferentials
oralgebra_generators
? It's nice thatW.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/betterdesign to implement a custom morphism (like for a module with basis using module_morphism
).
comment:143 in reply to: ↑ 142 ; followup: ↓ 144 Changed 8 years ago by
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 thevariables
method can return its elements in a random order, not necessarily alphabetical. Will the same happen withdifferentials
oralgebra_generators
? It's nice thatW.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 adict
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 classlevel 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
, thencoerce_map_from
creates a map using_element_constructor_
. There are times when it's easier/betterdesign to implement a custom morphism (like for a module with basis usingmodule_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 8 years ago by
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 classlevel docstring forDifferentialWeylAlgebra
and/or to theweyl_algebra
methods for polynomial rings (pointing out that the result ofinject_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 followup: ↓ 146 Changed 8 years ago by
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 metaticket.
comment:146 in reply to: ↑ 145 Changed 8 years ago by
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 metaticket.
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 followup: ↓ 148 Changed 8 years ago by
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?
comment:148 in reply to: ↑ 147 Changed 8 years ago by
Replying to darij:
I think we should strive to have
algebra_generators
behave asgens
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 8 years ago by
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 8 years ago by
 Commit changed from b47af6ae9f8dd1e6d870ec986f81fb6913d12e16 to 53a9d7e6e93156fbf36fcfc0bf2c9b1109a1a679
Branch pushed to git repo; I updated commit sha1. New commits:
53a9d7e  Families return output based on order of variable names. Fixed coercion issue.

comment:151 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
 Commit changed from 53a9d7e6e93156fbf36fcfc0bf2c9b1109a1a679 to 339b71d736c66aba83aa60899578558a0d182fca
Branch pushed to git repo; I updated commit sha1. New commits:
339b71d  Fixed some typos.

comment:154 Changed 8 years ago by
 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 8 years ago by
 Status changed from needs_review to positive_review
comment:156 Changed 8 years ago by
Thank you both!
comment:157 Changed 8 years ago by
 Commit changed from 339b71d736c66aba83aa60899578558a0d182fca to 86982750ec7fcf5a9a531702ee038dc26cadb401
 Status changed from positive_review to needs_review
comment:158 Changed 8 years ago by
 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. 23; 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 Cliffordexterior 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 8 years ago by
 Status changed from needs_review to needs_work
sage t long warnlong 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 8 years ago by
 Commit changed from 86982750ec7fcf5a9a531702ee038dc26cadb401 to a002f4b47f23dea0b0dcd7b5dbf80a98af85b091
Branch pushed to git repo; I updated commit sha1. New commits:
a002f4b  Some tweaks to lifted_bilinear_form and fixed doctest.

comment:161 Changed 8 years ago by
 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 8 years ago by
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 8 years ago by
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 8 years ago by
 Commit changed from a002f4b47f23dea0b0dcd7b5dbf80a98af85b091 to ff27bdc5d87967d0e7fd5c1305cef4340db816c7
Branch pushed to git repo; I updated commit sha1. New commits:
ff27bdc  further fixes

comment:165 Changed 8 years ago by
 Status changed from needs_review to positive_review
Ah yea. Duh. Thanks.
comment:166 Changed 8 years ago by
 Branch changed from public/algebras/weyl_clifford15300 to ff27bdc5d87967d0e7fd5c1305cef4340db816c7
 Resolution set to fixed
 Status changed from positive_review to closed
New commits: