Skip to content

Define SectorUnitRange and refactor GradedUnitRange #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 33 commits into
base: main
Choose a base branch
from

Conversation

ogauthe
Copy link
Contributor

@ogauthe ogauthe commented Apr 15, 2025

This PR is a work in progress for a refactor of GradedUnitRange, following the interface defined in https://gist.github.com/ogauthe/b22450c66b5ad937db47b49cd8e6b1cb.

This implementation does not use LabelledNumbers. Instead it is based on a "full range", which take into account multi-dimensional irreps:

struct SectorUnitRange{T,Sector,Range<:AbstractUnitRange{T}} <: AbstractUnitRange{T}
  nondual_sector::Sector
  full_range::Range
  isdual::Bool
end

const SectorOneTo{T,Sector,Range} = SectorUnitRange{T,Sector,Base.OneTo{T}}

struct GradedUnitRange{
  T,BlockLasts,BR<:AbstractBlockedUnitRange{T,BlockLasts},SUR<:SectorOneTo{T}
} <: AbstractGradedUnitRange{T,BlockLasts}
  sectors::Vector{SUR}
  range::BR
end

const GradedOneTo{T,BlockLasts,BR,SUR} = GradedUnitRange{T,BlockLasts,BR,SUR} where {BR<:BlockedOneTo}

There is still work to be done to update all methods. Some interface choices are open for discussion (accessors...). However I realized there is an issue with the current plan: it cannot handle non-group categories. Indeed the objective is to have length(full_range) == quantum_dimension and to iterate on the axis to reach any state. This is not compatible with non-integer quantum dimension. Concerning structure, Base.OneTo, BlockedUnitRange and BlockedOneTo impose Integer eltype, we cannot directly use them with e.g. Fibonacci.

The problem is serious, there is a real incompatibility between iterating on an axis and non-integer length. There are several possibilities:

  • conservative: drop length = quantum_dimension and keep the current length = multiplicity convention.
  • radical: drop non-group category. A full implementation requires additional features (braiding) that are not currently planned, we would not loose functionality.
  • intermediate: store (integer based) multiplicity axes in the implementation and have methods that may return float. This does not solve the question "how to iterate on such an axis`.

@ogauthe ogauthe marked this pull request as draft April 15, 2025 14:36
Copy link

codecov bot commented Apr 15, 2025

Codecov Report

Attention: Patch coverage is 97.49104% with 7 lines in your changes missing coverage. Please review.

Project coverage is 95.48%. Comparing base (667e788) to head (04e07aa).

Files with missing lines Patch % Lines
src/abstractsector.jl 83.78% 6 Missing ⚠️
src/gradedunitrange_interface.jl 94.44% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##             main      #22       +/-   ##
===========================================
+ Coverage   81.57%   95.48%   +13.91%     
===========================================
  Files          29       19       -10     
  Lines         939      665      -274     
===========================================
- Hits          766      635      -131     
+ Misses        173       30      -143     
Flag Coverage Δ
docs 0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@mtfishman
Copy link
Member

For non-group categories, my intuition would be to just accept that for those cases, length(::SectorUnitRange) and length(::GradedUnitRange) are not integers and iterating over elements of those ranges is not defined, but you could still define operations like blockwise slicing, slicing ranges of multiplicities (using the Kronecker slicing notation we discussed), etc.

@mtfishman
Copy link
Member

In those cases, I guess the types SectorUnitRange and GradedUnitRange don't make sense since those are wrapping unit ranges/blocked unit ranges, so maybe that can be handled with some other axis type.

@ogauthe ogauthe marked this pull request as ready for review April 25, 2025 01:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants