q-commuting polynomials

[tscrim]

These show up in quantum mechanics computations and are a variation of skew commuting polynomials (cf. the exterior algebra) satisfying yx = q^{B_xy} xy for all variables that index fixed a skew symmetric bilinear matrix B.

We provide a simple initial implementation.

CC: @fchapoton

Component: algebra

Keywords: q-commuting polynomials

Author: Travis Scrimshaw

Branch/Commit: 49129ea

Reviewer: Frédéric Chapoton

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

[tscrim]

Commit: d7f05ce

[tscrim]

Branch: public/algebras/q_commute_polys-34412

[tscrim]

comment:1

Here is a very simple implementation for them that feeds off as much as possible. Likely could be improved (e.g., not relying on FreeMonoid as a backend for the basis), but it works for now.

---

New commits:

d7f05ce

Initial implementation of q-commuting polynomials.

[sagetrac-git]

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

49129ea

Allowing an arbitrary skew-symmetric matrix as input to determine the multiplication.

[sagetrac-git]

Changed commit from d7f05ce to 49129ea

[tscrim]

comment:4

Bot is green.

[fchapoton]

comment:5

ok, ok. I was just wondering for myself whether this fits into the setting of Ore algebras, and hence could be done using the "ore_algebra" package.

[tscrim]

comment:6

Thanks for looking at this. I didn't mean to pressure you into it.

I thought about that too. However, that viewpoint makes one of the variables more special than the others, which is not desirable to me. For example, if we take two variables R[x,y]_q, then to consider this as an Ore algebra, we take it to be the Ore extension R[y][x; phi], where phi(y) = qy. For more variables, we would then iterate this construction, leading us to something like R[x_n][x_{n-1}; phi_n] ... [x_2; phi_3][x_1; phi_2], which would be isomorphic but different for any ordering of the variables. Contrast this with R['x,y'] and R['x']['y'] and R['y']['x'] as polynomial rings within Sage. I suspect this will also be slower too.

[fchapoton]

comment:7

is there any other structure on that algebra ? a coproduct or co-module structure ?

With just x and y, this is sometimes called the quantum plane, right ?

minor remark:

return tuple([self.monomial(g) for g in self._indices.gens()])

could create directly the tuple

[tscrim]

comment:8

Replying to @fchapoton:

is there any other structure on that algebra ? a coproduct or co-module structure ?

I am not sure. I will do some searching.

With just x and y, this is sometimes called the quantum plane, right ?

Yes, it does. Should I add this as a comment to the doc? (Hopefully you can respond quickly as I will be leaving for home soon.)

minor remark:

return tuple([self.monomial(g) for g in self._indices.gens()])

could create directly the tuple

It is actually (slightly) faster for whatever reason to do tuple([generator]) than tuple(generator):

sage: %timeit T = tuple(i for i in range(100))
2.33 µs ± 13.5 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
sage: %timeit T = tuple([i for i in range(100)])
1.44 µs ± 17 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Still remains completely counterintuitive to me.

[tscrim]

comment:9

So it doesn't seem like they are not known to carry any further natural structure since I can't find anything about that in this survey:

https://link.springer.com/article/10.1007/BF02355445

Although we can build a comodule structure on them using the quantum coordinate ring of SL_n as a generalization of exercise (3) in Section 3.4 of

http://www.mate.unlp.edu.ar/~ggarcia/encuentros/notas-curso-qg-ha.pdf

Maybe in Sage we should call them QuantumPolynomials? That is probably a better name than what I initially chose. I wasn't very happy with the name.

There is a slightly more general construction that could be done with q_{ij} not being q^{b_{ij}} but more generally q_{ij} q_{ji} = 1. Although that might be best for a followup ticket as that will be a fairly different implementation.

[fchapoton]

comment:10

ok, let's not bother more. I am setting to positive.

[fchapoton]

Reviewer: Frédéric Chapoton

[tscrim]

comment:12

Thank you.

It’s definitely an interesting question as the classical case, and maybe even the related geometry, suggests that there should be additional structure (maybe also from the iterated Ore extensions).

What do you think about the name though? Would you say QuantumPolynomials is better than qCommutingPolynomials?

A more trivial point but do you think I should add a quantum plane note to the doc before we merge this initial version?

[fchapoton]

comment:13

oh, well, you can add a comment and set back to positive if you like.

for the name, I am ok with "qCommutingPolynomials". As far as I know, neither of your proposed name is very standard

[tscrim]

comment:14

I feel lazy ^^;;. I might do all of that on a follow up ticket if I end up wanting to extend the functionality or come across some further references.

Thank you again.

[fchapoton]

comment:15

yes, ok. In the same vein, an idea is that the Laurent version (quantum torus algebras) could be of interest to people doing cluster algebras.

[tscrim]

comment:16

That’s a good idea of something to implement. It is just a relatively small tweak of my code to use the FreeAbelianGroup or ZZ^n instead (with most of the work likely just dealing with different implementation details of the indexing set).

[tscrim]

comment:17

Follow is #34472.

[vbraun]

Changed branch from public/algebras/q_commute_polys-34412 to 49129ea