Add experimental support for wreath Macdonald polynomials

[RaphaelPaegelow]

This PR is adding the computation of wreath Macdonald polynomials to Oscar.

[ulthiel]

Without having looked at the code at all, this in principle has very much my support!

Ok, I have looked quickly at the code. I think the dependency on Chevie will be a major problem, since this conflicts basically with everything in OSCAR:

import Chevie: complex_reflection_group, charinfo, CharTable, CyclotomicNumbers

In principle this should be possible to "fix" when basing this on my not-finished PR on complex reflection groups (#3342).......

[fingolfin]

Thank you for your contribution! One quick note: new code like this should probably go into the "experimental" directory as described at https://docs.oscar-system.org/dev/Experimental/intro/ ; you may also wish to have a look at https://docs.oscar-system.org/dev/DeveloperDocumentation/new_developers/

[lgoettgens]

I added some comments that should hopefully help you a bit with the experimental structure, and to get the code running again

[lgoettgens]

great progress. I found some few julia performance pitfalls that should be pretty easy to adapt here

[RaphaelPaegelow]

I have removed Chevie as a dependency thanks to #4821.
I will now improve readability of the output of wreath_macs.

[lgoettgens]

two small typos in docstrings that don't match the latest changes. apart from that, I have no objections to merging this (although have haven't checked the mathematics)

[ulthiel]

Sorry, can someone show me a screenshot/pdf whatever of the documentation? I forgot how to pull this.

[fingolfin]

@ulthiel easiest to "pull this" might be to install gh (see https://cli.github.com) and then just do gh pr checkout 4797 in your Oscar clone).

But I did it for you and attach a PDF export of the relevant manual section.
Wreath Macdonald polynomials · Oscar.pdf

[fingolfin]

Ahhh, I am sorry, but here are yet some more comments -- but we could also do them later. But at least the typo fixes etc. hopefully cause no harm.

I'll approve anyway because I think it's fine even as it is, just could be even better ;-).

Might be nice to wait a little bit in case @ulthiel has mathematical feedback

[fingolfin]

The kwarg type is overly specific, this should be enough

Suggested change

	parent::AbstractAlgebra.Generic.MPolyRing{QQAbFieldElem{AbsSimpleNumFieldElem}})
	parent::MPolyRing{<:QQAbFieldElem})

[fingolfin]

Let's provide a default parent for the user's convenience:

Suggested change

	parent::AbstractAlgebra.Generic.MPolyRing{QQAbFieldElem{AbsSimpleNumFieldElem}})
	parent::MPolyRing{<:QQAbFieldElem} = polynomial_ring(K,[:q,:t];cached=false))

Actually I think we have allowed this to be a cached ring for added convenience in other cases? @thofma ?

Suggested change

	parent::AbstractAlgebra.Generic.MPolyRing{QQAbFieldElem{AbsSimpleNumFieldElem}})
	parent::MPolyRing{<:QQAbFieldElem} = polynomial_ring(K,[:q,:t];cached=true))

[RaphaelPaegelow]

Isn't polynomial_ring returning a tuple?
By default I can cache the ring if that is more convenient.

[RaphaelPaegelow]

I changed it to parent::MPolyRing{<:QQAbFieldElem} = polynomial_ring(abelian_closure(QQ)[1],[:q,:t];cached=true)[1]).

[fingolfin]

Suggested change

	Given two integers n and r and an element of the affine Weyl group of type A (seen as
	Given two integers `n` and `r` and an element of the affine Weyl group of type A (seen as

[fingolfin]

Suggested change

	all multipartition of size n and length r in the standard Schur basis indexed by the
	all multipartition of size `n` and length `r` in the standard Schur basis indexed by the

[fingolfin]

Suggested change

	the semi-direct product of the Symmetric group with the coroot lattice), this function
	the semi-direct product of the symmetric group with the coroot lattice), this function

You write "the" symmetric group -- but there are many? Perhaps "the symmetric group of degree XYZ" and then replace XYZ with a suitable value. Otherwise, "a" symmetric group?

[ulthiel]

I have some comments on the documentation, see attached.
Wreath.Macdonald.polynomials.Oscar.pdf

[RaphaelPaegelow]

Ahhh, I am sorry, but here are yet some more comments -- but we could also do them later. But at least the typo fixes etc. hopefully cause no harm.

I'll approve anyway because I think it's fine even as it is, just could be even better ;-).

Might be nice to wait a little bit in case @ulthiel has mathematical feedback

Thanks a lot for all your comments.

[RaphaelPaegelow]

I have some comments on the documentation, see attached. Wreath.Macdonald.polynomials.Oscar.pdf

Thank you very much for your comments. I have implemented your recommendations and have reorganized a bit the documentation. I just don't exactly know which definitions I should add. Could you precise what you mean? I started to write something but quickly realized that I was summarizing Orr's and Shimozono's survey.

[ulthiel]

I have some comments on the documentation, see attached. Wreath.Macdonald.polynomials.Oscar.pdf

Thank you very much for your comments. I have implemented your recommendations and have reorganized a bit the documentation. I just don't exactly know which definitions I should add. Could you precise what you mean? I started to write something but quickly realized that I was summarizing Orr's and Shimozono's survey.

I (maybe just me) think it would be nice if the documentation would be somewhat self-contained so that I do not have to go and read a paper to find somewhere in it the definition of the objects the functions return. It must be possible to summarize this in a couple of paragraphs.

[fingolfin]

While agree with @ulthiel that "somewhat self-contained documentation" would be preferable, let's not forget that this Pr targets experimental. So it is perfectly fine to merge it now and make those improvements later.

I've fixed two minor issues directly now, if tests pass, let's merge this, and hopefully @RaphaelPaegelow will consider tweaking the docs in a follow-up PR.