WIP - Permutation Groupoid #707

ssteakley · 2022-11-09T18:40:24Z

This is a chunk of the work I've been doing toward implementation of #231. The main result here is the implementation of FinBijectionCycles: a concrete type for finite automorphisms that are backed by a set of cycles. Cycles are implemented as CircularVectors, from CircularArrays.jl, which are wrapped so that we can provide appropriate implementations of == and hash.

The commit also introduces an abstract type SetBijection <: SetFunction and redeclares IdentityFunction <: SetBijection.

Potential Issues:

Calculation of function values for FinBijectionCycles, as implemented here, is meaningfully slower than for vector-backed and dict-backed FinFunctions. If the underlying data of the function is truly going to be a set of cycles, then I'm not sure how the speed can be improved. It seems that some transformation would need to be computed.
For f :: FinBijectionCycles, show(f) doesn't look great.
This WIP was largely inspired by the preexisting implementations of the FinFunction types. Maybe this has been somewhat preempted, or superceded, by other ongoing work. Namely, the refactor of FinFunctions to use Columns.

Feedback would be greatly appreciated!

ssteakley · 2023-07-02T20:39:04Z

After some more work on this, trying to speed up composition for FinBijectionCycles, I now feel that this approach may be inherently too slow. Representing a bijection by a set of Cycles matches up intuitively with the mathematical cycle notation, but it is an unwieldy representation for computing function values and composites. This PR's algorithm for computing values, for example, is worst case O(n) for n the size of the domain. I wonder, would there be other advantages to this representation that would make it worth these instances of bad performance?

One alternative would be to store the mapping in a more usual way, either as a Vector or Dict, and then store the cycles themselves as metadata. Essentially, the mapping would be a wrapper around a FinBijectionDict or FinBijectionVector with some metadata. In the interest of performance, composition of two FinBijectionCycles probably should not return another FinBijectionCycles, since this would require the metadata (the new set of cycles, themselves) to be recomputed from scratch.

ssteakley · 2023-07-04T03:20:17Z

More and more I am thinking that implementing Bijections as wrapper types, with SetFunctions inside, is what makes the most sense. For me, this goes together with the insight that, for most purposes, if you are going to compute the cycles of a FinBijection, you may as well compute and store its inverse at the same time. Both require computing the same data in a loop over the mapping's domain. This suggests that the implementation of FinBijectionCycles could profitably be based on that of a type BijectionBimap, which would represent a bijection as a pair of (inverse) functions. Computing the inverse along with the cycles is, of course, a little slower, and takes more space. But as a consequence, the resulting object is perhaps more faithful to mathematical cycle notation: indeed, a written set of cycles displays the inverse mapping "alongside" the mapping itself, truly on equal footing.

ssteakley · 2023-07-10T22:17:18Z

I have reimplemented FinBijectionCycles based on a system of wrapper types which represent bijections. Now, a FinBijectionCycles object is just a pair of inverse SetFunctions (i.e. a BijectionBimap) with the cycles themselves attached as ancillary data. Some odds and ends are still missing (e.g. an appropriate show method for FinBijectionCycles), but the code is passing tests for basic functionality.

As I explain in a # developer's note in src/CategoricalAlgebra/Sets.jl, the extant implementation of CompositeFunction is disadvantageous for my implementation of composition with inverses. The crucial fact is that iterated composites result in a tree-like structure of nested CompositeFunctions, and the type information of the "root" of the tree does not convey the types of the leftmost and rightmost functions of the composite. In my implementation, this leads to an inevitable efficiency loss when using compose with any CompositeFunction. The obvious idea for a way forward would be to try refactoring CompositeFunction to store a list of SetFunctions instead of a pair, thus eliminating the need to form nested CompositeFunctions and allowing the type to expose the types of the leftmost and rightmost functions.

jpfairbanks · 2023-08-07T20:58:03Z

src/categorical_algebra/FinSets.jl

+  BijectionThinWrap(FinFunction(f, args...))
+
+function FinBijection(f::Union{AbstractDict{K,Int},AbstractVector{Int}}) where K
+  function minandmax(p::Tuple{<:Number, <:Number}, n::Int)::Tuple{Int,Int}


This is a little overzealous for a type assert, the julia compiler will infer this method correctly.

jpfairbanks · 2023-08-07T20:59:57Z

src/categorical_algebra/FinSets.jl

+  function minandmax(p::Tuple{<:Number, <:Number}, n::Int)::Tuple{Int,Int}
+    (Int(min(p[1], n)), Int(max(p[2], n)))
+  end
+  minval, maxval = reduce(minandmax, values(f), init=(Inf, -Inf))


Maybe use typemax(Int), typemin(Int) for this sentinel value, since Inf and -Inf are Float64. You probably also want to return the min, then the max so that you can interpret it as a range. min:max

Thanks, will change the sentinel value. About the ordering thing, if I'm not misunderstanding you, minandmax is already returning the values in that order, as is.

nevermind that. reading min and max too many times in a row, I forgot which is which.

jpfairbanks · 2023-08-07T21:02:41Z

src/categorical_algebra/Sets.jl

+(f::AbsBijectionWrap)(x) = (unwrap(f))(x)
+
+# Developer's note: should I add in a `known_correct` parameter, asking
+# the caller to decide whether the SetFunction should be checked for bijectivity?


yes, that is usually how we enable optional correctness checking.

jpfairbanks · 2023-08-07T21:03:50Z

src/categorical_algebra/Sets.jl

+
+# Developer's note: should I add in a `known_correct` parameter, asking
+# the caller to decide whether the SetFunction should be checked for bijectivity?
+@struct_hash_equal struct BijectionThinWrap{Dom<:SetOb, Codom<:SetOb,


Thin has a technical meaning in CT, that there is at most one morphism between two objects. Here I think you are just meaning "thin wrapper" like a lightweight wrapper type. It would be good to avoid the word thin for this non-jargon usage.

jpfairbanks · 2023-08-07T21:05:10Z

src/categorical_algebra/Sets.jl

+
+function Base.show(io::IO, f::BijectionThinWrap)
+  replacerules = (r"^SetFunction" => "Bijection", r"^FinFunction" => "FinBijection")
+  print(io, replace(repr(f.func), replacerules...))


Make sure to include a test for this so that we can detect breakage. I can imagine changing the "SetFunction" and this pattern not matching any more.

jpfairbanks · 2023-08-07T21:08:17Z

src/categorical_algebra/Sets.jl

+# for `compose_inv`, the obvious idea would be to try refactoring
+# `CompositeFunction` to store a list of `SetFunction`s instead of a pair.
+
+function compose_inv(f::SetFunction, g::SetFunction)


I think this might be easier with MLStyle pattern matching and structural recursion.

…nWrap` to `BijectionWrapper`

- Rewrite `comp_inv_helper` with MLStyle pattern matching - Reconceive `BijectionBimap`, allowing it to contain instances of `AbsBijectionWrapper` - Reconceive `do_inv`, making it return a `Bijection` - Tighten up `minandmax` definition - Implement specific `do_compose` for `BijectionBimap`s

ssteakley · 2023-09-06T13:29:39Z

Thanks for the comments @jpfairbanks ! For now, I decided not to worry about implementing the known_correct parameter and corresponding checkers; that can wait. I addressed the other comments, and made a couple more changes. If this is looking acceptable, then I could try to proceed with the rest of the code for the permutation groupoid.

Other needed steps:

Write more tests/improve coverage

mehalter force-pushed the master branch from 1defabf to c53d058 Compare March 27, 2023 14:11

A few type definition adjustments; clean up a couple functions

b467b58

ssteakley force-pushed the permutation-groupoid branch from 850004e to f917260 Compare July 10, 2023 21:54

Implement FinBijectionCycles based on Bijections as wrapper types

15dffb0

ssteakley force-pushed the permutation-groupoid branch from f917260 to 15dffb0 Compare July 10, 2023 22:08

jpfairbanks reviewed Aug 7, 2023

View reviewed changes

ssteakley added 2 commits September 4, 2023 22:30

Rename AbsBijectionWrap to AbsBijectionWrapper, and `BijectionThi…

b79f791

…nWrap` to `BijectionWrapper`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP - Permutation Groupoid #707

WIP - Permutation Groupoid #707

ssteakley commented Nov 9, 2022

ssteakley commented Jul 2, 2023 •

edited

Loading

ssteakley commented Jul 4, 2023

ssteakley commented Jul 10, 2023 •

edited

Loading

jpfairbanks Aug 7, 2023

jpfairbanks Aug 7, 2023

ssteakley Aug 10, 2023

jpfairbanks Aug 10, 2023

jpfairbanks Aug 7, 2023

jpfairbanks Aug 7, 2023

jpfairbanks Aug 7, 2023

jpfairbanks Aug 7, 2023

ssteakley commented Sep 6, 2023 •

edited

Loading

WIP - Permutation Groupoid #707

Are you sure you want to change the base?

WIP - Permutation Groupoid #707

Conversation

ssteakley commented Nov 9, 2022

ssteakley commented Jul 2, 2023 • edited Loading

ssteakley commented Jul 4, 2023

ssteakley commented Jul 10, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ssteakley commented Sep 6, 2023 • edited Loading

ssteakley commented Jul 2, 2023 •

edited

Loading

ssteakley commented Jul 10, 2023 •

edited

Loading

ssteakley commented Sep 6, 2023 •

edited

Loading