Experimental: Complex reflection groups

[ulthiel]

This is work in progress implementing complex reflection groups. Contributions welcome.

[fingolfin]

Thanks that's a great contribution!

A few quick comments

[lgoettgens]

Could you click "resolve conversation" on all comments above once you addressed them? This makes it way easier to keep an overview here.

[ulthiel]

Could you click "resolve conversation" on all comments above once you addressed them? This makes it way easier to keep an overview here.

Yes, once addressed... ;-)

[thofma]

If you change the Hecke version in the file Oscar/src/Project.toml to 0.30.2, you should be able to get rid of complex_conjugation2.

[ulthiel]

If you change the Hecke version in the file Oscar/src/Project.toml to 0.30.2, you should be able to get rid of complex_conjugation2.

Excellent. I will when I'm done (ETA next week).

[ulthiel]

If you change the Hecke version in the file Oscar/src/Project.toml to 0.30.2, you should be able to get rid of complex_conjugation2.

Done in efbb6e5.

[ulthiel]

Can someone (@joschmitt @lgoettgens) help me with the failing tests? This seems to be a problem with experimental/LieAlgebras and the function coroot, which I have implemented (with a different signature) as well.

The error is "MethodError: no method matching coroot(::RootSystem, ::Int64)"

[joschmitt]

Can someone (@joschmitt @lgoettgens) help me with the failing tests? This seems to be a problem with experimental/LieAlgebras and the function coroot, which I have implemented (with a different signature) as well.

The error is "MethodError: no method matching coroot(::RootSystem, ::Int64)"

Adding

import Oscar.LieAlgebras: coroot

in ComplexReflection.jl seems to work. (Don't ask me why; this import/export nonsense is always educated guessing at best for me.)

[ulthiel]

Thanks, let's see if it works.

[joschmitt]

The "long tests" seem to fail because you export is_exceptional and is_shephard_group without having them?

[ulthiel]

Ok, checks passed finally. I will need to document the functions, add further documentation, and address the stuff from the top of this conversation. Then it should be OK for a first set of features for complex reflection groups (this can never be finished...).

[lgoettgens]

some random comments and nitpickts

[lgoettgens]

In my opinion, this shouldn't be needed as there already is dot for a dot-product. But unfortunately, that does not work for non-real fields currently (see Nemocas/Nemo.jl#1694), so this might only be possible to change in the later future.

[ulthiel]

No, and for exactly the reason you say: I need to involve complex conjugation on the field.

[fingolfin]

First off, to avoid misunderstandings, let me emphasize that I am OK with merging this as it is for now.

But I still would like to clear this up on the long run. Perhaps it is already clear for @thofma and @fieker but I am not familiar with the background, so I am asking / pointing out the following:

First off, dot as defined in Julia, does involve complex conjugation:

Compute the dot product between two vectors. For complex vectors, the first vector is conjugated.

However, it doesn't work on AbstractAlgebra.Generic.FreeModuleElem. For starters iteration over these is not implemented. Nor is conj implemented for most of our types. Which makes me wonder: why not? We could just add

Base.conj(x::ZZRingElem) = x
Base.conj(x::ZZPolyRing) = x
Base.conj(x::ZZMPolyRing) = x

Base.conj(x::QQFieldElem) = x
Base.conj(x::QQPolyRing) = x
Base.conj(x::QQMPolyRing) = x

...

[thofma]

dot implies conjugation on the first vector, where as @ulthiel wants it on the second vector. We use the same convention as @ulthiel for inner_product.

I think adding conj for ring elements, which are contained in the complex numbers is fine. Although I am not sure I want to extend it automatically to polynomials.

[ulthiel]

Okay thanks all. I'll need a bit to address everything...

[ulthiel]

What is this failing invalidations?

[lgoettgens]

What is this failing invalidations?

If the difference is less than 5 (see e.g. https://github.com/oscar-system/Oscar.jl/actions/runs/8202710398 for the current report), this can be ignored and will usually go away when restarting enough times.

[codecov]

Codecov Report

Attention: Patch coverage is 76.45474% with 437 lines in your changes missing coverage. Please review.

Project coverage is 83.86%. Comparing base (71c1f3e) to head (084f0b0).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3342      +/-   ##
==========================================
- Coverage   84.00%   83.86%   -0.14%     
==========================================
  Files         592      603      +11     
  Lines       81624    83480    +1856     
==========================================
+ Hits        68566    70009    +1443     
- Misses      13058    13471     +413     

Files	Coverage Δ
...l/ComplexReflectionGroups/src/dual_vector_space.jl	100.00% <100.00%> (ø)
...erimental/ComplexReflectionGroups/test/runtests.jl	100.00% <100.00%> (ø)
experimental/Experimental.jl	88.23% <ø> (ø)
...al/ComplexReflectionGroups/src/hermitian_things.jl	92.85% <92.85%> (ø)
...al/ComplexReflectionGroups/src/is_root_of_unity.jl	54.83% <54.83%> (ø)
...eflectionGroups/src/symplectic_reflection_group.jl	0.00% <0.00%> (ø)
...ectionGroups/src/complex_reflection_group_Magma.jl	93.86% <93.86%> (ø)
...eflectionGroups/src/complex_reflection_group_LT.jl	92.37% <92.37%> (ø)
...ctionGroups/src/complex_reflection_group_CHEVIE.jl	91.49% <91.49%> (ø)
...exReflectionGroups/src/complex_reflection_group.jl	45.12% <45.12%> (ø)
... and 2 more

... and 2 files with indirect coverage changes

[fingolfin]

This is still marked as "draft". @ulthiel what is missing from your POV before this can be merged?

I worry a bit about drift happening to this PR (already there is a conflict, though it should be trivial to resolve). I would recommend to merge this rather earlier than later; since it is in experimental, it would still be fine to perform major rewrites later. But once merged at least we can take care of adjusting the code added here as needed to changes in AA/Nemo/Hecke/Julia, and can ensure its tests keep passing, etc.

That said, in the end you decided of course.

[ulthiel]

This is still marked as "draft". @ulthiel what is missing from your POV before this can be merged?

I worry a bit about drift happening to this PR (already there is a conflict, though it should be trivial to resolve). I would recommend to merge this rather earlier than later; since it is in experimental, it would still be fine to perform major rewrites later. But once merged at least we can take care of adjusting the code added here as needed to changes in AA/Nemo/Hecke/Julia, and can ensure its tests keep passing, etc.

That said, in the end you decided of course.

Will continue now.

[lgoettgens]

This PR now contains a lot of other changes not related to complex reflection groups. Could you try to rebase this onto a current master?

[ulthiel]

This PR now contains a lot of other changes not related to complex reflection groups. Could you try to rebase this onto a current master?

I do not know what this means: 1) changes not related to complex reflection groups? which? 2) rebase? what do I need to do?

[lgoettgens]

The commit 6d76ba2 contains other changes.
I think you would need to drop that and instead do a proper merge/rebase. I.e. after dropping that commit do:

git checkout yourbranch
git rebase upstream/master

And then follow the instructions in the console to resolve conflicts given by typing git status

[ulthiel]

Ok, is it better now? I have no idea what I just did. I had to resolve conflicts in Experimental.jl and oscar_references.bib several times. My tests passed and I could build the documentation without errors.

[ulthiel]

What I still want to do before a merge is the following:

• Finish up documentation
• Function to determine conjugacy classes of reflections and hyperplane orbits, and extend the ComplexReflection type to carry a reference to the conjugacy class and hyperplane orbit. I need to think about how to do this nicely. I need this for Calogero-Moser spaces and Cherednik algebras. Since this may change ComplexReflection a bit, I first want to figure this out before merge.