Add basics for quantum analogs

[ulthiel]

Added basic functions for quantum analogs that I had implemented in my JuLie package: quantum integers, factorials, and binomials. They work also with specializations in any (commutative) ring.

[codecov]

Codecov Report

Attention: Patch coverage is 98.36066% with 1 line in your changes missing coverage. Please review.

Project coverage is 85.55%. Comparing base (e3f1503) to head (bd4d75c).
Report is 490 commits behind head on master.

Files with missing lines	Patch %	Lines
experimental/QuantumAnalogs/src/QuantumAnalogs.jl	98.36%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2183      +/-   ##
==========================================
+ Coverage   84.01%   85.55%   +1.54%     
==========================================
  Files         592      703     +111     
  Lines       81674   117704   +36030     
==========================================
+ Hits        68617   100706   +32089     
- Misses      13057    16998    +3941     

Files with missing lines	Coverage Δ
experimental/QuantumAnalogs/src/QuantumAnalogs.jl	98.36% <98.36%> (ø)

... and 363 files with indirect coverage changes

[fingolfin]

Thank you, this looks really good!

I still have a bunch of remarks, but most of these are on the cosmetically level, or optional, or both.

[ulthiel]

Thanks, @fingolfin. I had a discussion with @fieker: the function quantum_integer(n) may be problematic as is minimal_polynomial without passing the ring. He also suggested to implement a structure for quantum integers (so, basically the ring of quantum integers). I think this would be the way to go. I never thought about that before. That's why I changed the PR to draft mode.

[thofma]

Just wanted to say that I was in need of quantum binomial coefficients today and the changes here would have come in handy.

[ulthiel]

Just wanted to say that I was in need of quantum binomial coefficients today and the changes here would have come in handy.

Will do the update in the next couple of weeks. (I personally decided against implementing a dedicated ring as mentioned above for now, I hope you didn't need that particular feature...).

[fingolfin]

I've discussed this PR this morning with @ulthiel and based on that I've now rebased it -- doing this I noticed that a bit more work was needed than I expected, and as a result I've now moved it into a new experimental/QuantumAnalogs/ directory. But the final place for this probably should be in src/Combinatorics.

Unfortunately this move resulted in the existing comments on this file to loose their place, i.e. they are no longer attached to the relevant code :-(. Since that was the case now anyway, I've decided to also perform the changes from tabs to spaces (I didn't do those at first in the hopes that the code review comments would stay attached). I also performed some other "obvious" tweaks.

But I did not e.g. touch the unicode, or move anything to the .md file. @ulthiel I am happy to help with that, too, but it's the kind of change I wouldn't want to make w/o coordinating with you.

[fingolfin]

I've revised the PR now, and from my point of view this is ready for review and merging. @ulthiel I'll remove the "Draft" flag now, based on our discussion last week. Please holler if you have concerns.

[micjoswig]

As Max said above, I would like to have a more concise way of writing q-analogues (when used with quantum groups). Here is some sample code to illustrate the issue:

U = quantum_group(:B, 3)
qi = quantum_parameters(U)
F = gens(U)
f = F[7]^2*F[9]^2*F[1]^4/(quantum_factorial(2, qi[7]))*quantum_factorial(2, qi[9]))*quantum_factorial(4, qi[1]))

I agree that this would be nice to have. Is suitable code available? For if it is not, then we should proceed now with merging the existing code by @ulthiel after a final decision by @fingolfin concerning the interface.

[fingolfin]

Perhaps we can have a zoom call with @ulthiel @felix-roehrich and myself (and anyone else interested in actively using q-analogs) to settle on which user interface we want. Defaulting to the "combinatorics" meaning is fine, but we need to decide how to get "the other".

Triage had some mild preference for using rings (those who spoke up).

Also quantum_binomial vs. q_binomial... Actually isn't the q in q-anlog historically not for "quantum" but for "q" as in "the order of a finite field"? That would suggest using the q_ prefix and not quantum_.

[ulthiel]

Sure. I don't have any strong opinions on anything.

About the q/quantum: I think you're right.

[felix-roehrich]

I am still experimenting with the usage in my quantum groups implementation, but it seems that caching wouldn't work with a ring and needs to be directly on the quantum group. Furthermore, it seems the only use case for "symmetric" version is the quantum groups implementation.
The consensus seems to be to default to the combinatorial version, so I think it is fine to merge this; it is only experimental.

[fingolfin]

The one thing we discussed and agreed on with various people but is not documented here (oops) is several of us come to the conclusion that we should call these "$q$-analogs" instead of "quantum analogs" because that's what most of the literature seems to do and the "q" originally wasn't for "quantum" either. Not even the literature linked in this PR calls them "quantum binomials" etc., and q_binomial is more in line with what other software uses.

So I just updated this PR to that convention. I am also now building the manual locally and will check it for content and formatting issues etc.

[micjoswig]

So I just updated this PR to that convention. I am also now building the manual locally and will check it for content and formatting issues etc.

Thx. Looks good to me.

[fingolfin]

There was an issue with the .bib file. Otherwise all looks good to me. Once CI passes this is fine to merge from my POV.