Problem Statement
The current solver implementation is strictly limited to single-dimensional optimization. Specifically:
- Single Score Optimization: Groups are balanced using exactly one continuous variable (
Score).
- Inflexible Separation: Separation constraints are limited to a single boolean flag (appending
* to names). Real-world scenarios often require balancing multiple categorical tiers (e.g., IPPT results: Gold, Silver, Pass).
- Rigid Group Sizing: The mathematical model forces even group sizes via
num_people // num_groups. Asymmetric constraints (e.g., configuring two groups of 3 and two groups of 5) are impossible.
- No Inclusion Constraints: There is no mechanism to force designated participants into the same group.
Proposed Solution
1. Data Schema Evolution
Deprecate the Name | Score schema. Transition to dynamic data mapping:
Name | Sep | Grp | Score1 | Score2 | ...
-
Sep (Separation): Accepts multi-character tags. The solver must distribute participants with identical Sep tags evenly across all groups.
-
Grp (Grouping): Accepts multi-character tags. The solver must assign all participants with identical Grp tags to the same group.
-
ScoreN: Dynamic support for $N$ continuous variables.
2. Multi-Objective Weighting
When $N > 1$ scores are detected, the UI must request a scalar weight $W_n$ for each score. The objective function will transition from a single absolute deviation to a weighted sum of absolute deviations across all score dimensions.
3. Custom Group Sizes
Introduce an explicit group size array to replace the automatic division logic. The UI must expose inputs for individual group capacities and validate that $\sum \text{Capacity}_g = \text{Total Participants}$ before passing the array to the solver.
4. Constraint Conflict Resolution (Soft vs. Hard Constraints)
Direct collisions between Sep and Grp tags will result in an INFEASIBLE model state (e.g., Participants A and B must be in the same group due to Grp, but must be separated due to Sep).
- Feature: Provide a configuration toggle allowing the user to select the priority constraint (
Sep > Grp or Grp > Sep).
- Solver Architecture: The high-priority constraint remains a hard model constraint (
model.Add(...)). The low-priority constraint must be implemented as a soft constraint by applying a penalty multiplier to the objective function when violated, allowing the solver to find a valid sub-optimal configuration instead of failing.
Problem Statement
The current solver implementation is strictly limited to single-dimensional optimization. Specifically:
Score).*to names). Real-world scenarios often require balancing multiple categorical tiers (e.g., IPPT results: Gold, Silver, Pass).num_people // num_groups. Asymmetric constraints (e.g., configuring two groups of 3 and two groups of 5) are impossible.Proposed Solution
1. Data Schema Evolution
Deprecate the
Name | Scoreschema. Transition to dynamic data mapping:Name | Sep | Grp | Score1 | Score2 | ...Sep(Separation): Accepts multi-character tags. The solver must distribute participants with identicalSeptags evenly across all groups.Grp(Grouping): Accepts multi-character tags. The solver must assign all participants with identicalGrptags to the same group.ScoreN: Dynamic support for2. Multi-Objective Weighting$N > 1$ scores are detected, the UI must request a scalar weight $W_n$ for each score. The objective function will transition from a single absolute deviation to a weighted sum of absolute deviations across all score dimensions.
When
3. Custom Group Sizes$\sum \text{Capacity}_g = \text{Total Participants}$ before passing the array to the solver.
Introduce an explicit group size array to replace the automatic division logic. The UI must expose inputs for individual group capacities and validate that
4. Constraint Conflict Resolution (Soft vs. Hard Constraints)
Direct collisions between
SepandGrptags will result in anINFEASIBLEmodel state (e.g., Participants A and B must be in the same group due toGrp, but must be separated due toSep).Sep>GrporGrp>Sep).model.Add(...)). The low-priority constraint must be implemented as a soft constraint by applying a penalty multiplier to the objective function when violated, allowing the solver to find a valid sub-optimal configuration instead of failing.