Experimental: Partitioned Permutations

[BjSchaefer]

This is a new module for working with partitioned permutations which are used in Free Probablility Theory. For more information see the Readme file.

The module uses the module SetPartitions which is currently in the folder experimentals. To compile properly, we needed to rename the project folder to ZPartitionedPermutations so that this folder is below the folder SetPartitions within the folder experimentals.

[benlorenz]

The module uses the module SetPartitions which is currently in the folder experimentals. To compile properly, we needed to rename the project folder to ZPartitionedPermutations so that this folder is below the folder SetPartitions within the folder experimentals.

Please add both folders to orderedpkgs instead:

Oscar.jl/experimental/Experimental.jl

Lines 15 to 22 in 222c200

	# If an experimental package A depends on another experimental package B, one
	# can add `"B", "A"` to `orderedpkgs` below to ensure that B is loaded before A.
	# DO NOT USE THIS UNLESS YOU KNOW THE CONSEQUENCES.
	# For more background, see https://github.com/oscar-system/Oscar.jl/issues/2300.
	const orderedpkgs = [
	"LieAlgebras",
	"BasisLieHighestWeight", # nees code from LieAlgebras
	]

[lgoettgens]

Thanks for your contribution! I have not much background in the mathematics involved, but will point out some general coding things.

The module uses the module SetPartitions which is currently in the folder experimentals. To compile properly, we needed to rename the project folder to ZPartitionedPermutations so that this folder is below the folder SetPartitions within the folder experimental.

Please add both folders in

Oscar.jl/experimental/Experimental.jl

Line 19 in 222c200

const orderedpkgs = [

together with a comment like the one already existent to specify the order of inclusion.

[lkastner]

I'll block merging until the comment of @benlorenz has been addressed. There is a dedicated mechanism for loading certain packages in an ordered fashion. The side effect is that if a dependency that is in experimental gets discarded, then so will any package depending thereupon.

has been addressed

[thofma]

Since this adds functions for SetPartition from experimental/SetPartition, is there a particular reason to not combine those too? Maybe with some generic "FreeProbabilityTheory" name? Or alternatively, would it be an option to move those methods to the SetPartition module?

[BjSchaefer]

The SetPartitions do not exactly contribute to Free Probability Theory but rather to certain compact quantum groups. However, it is very much an option to move the functions for SetPartitions to the corresponding module.

[thofma]

However, it is very much an option to move the functions for SetPartitions to the corresponding module.

I think that would be great.

The SetPartitions do not exactly contribute to Free Probability Theory but rather to certain compact quantum groups.

OK, that makes sense. I think what we want to avoid is having too many separated (but interdependent) modules in experimental. So if there are more things incoming in the same "broad" area (it could be "Free probability theory and quantum groups"), at some point we can and probably should think about consolidating things. Makes it also easier to move things from experimental to src (which should be the endgame).

Edit: These are just some things to keep in mind, nothing that should hold up this PR here.

[joschmitt]

@BjSchaefer Please mark the pull request as "ready for review" when you are done. I assume this is the case, but I did not follow all of the discussion, so I am not sure.

[joschmitt]

Thank you!
I don't know about the mathematics, but for experimental this certainly looks good enough.
Whoever has write access to master: this can be merged from my point of view.

[lgoettgens]

Two small nitpicks, otherwise no objections from my side. But as Johannes, I am not familiar with the mathematics involved.

[fieker]

On Tue, Apr 09, 2024 at 05:33:21AM -0700, Lars Göttgens wrote: @lgoettgens commented on this pull request. > + upper_points(cycle_partition(perm(symmetric_group(length(pp_1)), 1:length(pp_1))))) + end +end + +""" + factorization_partitioned_permutation(pp::PartitionedPermutation) + +Return the factorization of `pp` in form of a set of 2-tuples. + +# Examples +```jldoctest +julia> length(factorization_partitioned_permutation(partitioned_permutation(perm(symmetric_group(3), [2, 1, 3]), [1, 1, 2]))) +2 +``` +""" +function factorization_partitioned_permutation(pp::PartitionedPermutation) Sorry for not thinking this through before posting. `factorization`(s) seems to already exist in the Oscar universe while `factorize` does not. So `factorization` should be the preferred name I think.

factor is the usual Oscar name to obtain a factorisation. factorisations is for the special case of algebraic integers where all factorisations into irreducibles can be computed, but a single factorisation should "factor" I'd actually prefer: function factor(pp::PartitionedPermutation) as the signature - unless there is a reason to repeat the paritioned permutation bit in the name and the signature

…

-- Reply to this email directly or view it on GitHub: #3439 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[lgoettgens]

On Tue, Apr 09, 2024 at 05:33:21AM -0700, Lars Göttgens wrote: @lgoettgens commented on this pull request. > + upper_points(cycle_partition(perm(symmetric_group(length(pp_1)), 1:length(pp_1))))) + end +end + +""" + factorization_partitioned_permutation(pp::PartitionedPermutation) + +Return the factorization of pp in form of a set of 2-tuples. + +# Examples +jldoctest +julia> length(factorization_partitioned_permutation(partitioned_permutation(perm(symmetric_group(3), [2, 1, 3]), [1, 1, 2]))) +2 + +""" +function factorization_partitioned_permutation(pp::PartitionedPermutation) Sorry for not thinking this through before posting. factorization(s) seems to already exist in the Oscar universe while factorize does not. So factorization should be the preferred name I think.
factor is the usual Oscar name to obtain a factorisation. factorisations is for the special case of algebraic integers where all factorisations into irreducibles can be computed, but a single factorisation should "factor" I'd actually prefer: function factor(pp::PartitionedPermutation) as the signature - unless there is a reason to repeat the paritioned permutation bit in the name and the signature
…
-- Reply to this email directly or view it on GitHub: #3439 (comment) You are receiving this because you are subscribed to this thread. Message ID: @.***>

Thanks claus! I didn't remember this one.

[codecov]

Codecov Report

Merging #3439 (fc72cb6) into master (edb8c71) will decrease coverage by 0.45%.
Report is 29 commits behind head on master.
The diff coverage is 94.49%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3439      +/-   ##
==========================================
- Coverage   82.17%   81.72%   -0.45%     
==========================================
  Files         568      573       +5     
  Lines       77169    77488     +319     
==========================================
- Hits        63410    63330      -80     
- Misses      13759    14158     +399     

Files	Coverage Δ
experimental/Experimental.jl	78.57% <ø> (ø)
...rmutations/src/EnumeratePartitionedPermutations.jl	100.00% <100.00%> (ø)
...Permutations/src/PartitionedPermutationProducts.jl	100.00% <100.00%> (ø)
...itionedPermutations/src/PartitionedPermutations.jl	100.00% <100.00%> (ø)
experimental/SetPartitions/src/SetPartition.jl	100.00% <100.00%> (ø)
experimental/SetPartitions/src/SetPartitions.jl	100.00% <ø> (ø)
...titionedPermutations/src/PartitionedPermutation.jl	79.31% <79.31%> (ø)

... and 40 files with indirect coverage changes