Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Shadow variable or predicate Pinning

Aperta
  • Qualcosa non va?
#2,471 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
java, kotlin
Ambito
ai

Direzione di ricerca

No files, tests, or entry points are named. Start by reviewing the solver's existing entity pinning and move-evaluation behavior, then compare the proposed shadow-variable and predicate approaches; done requires an agreed API and defined handling for initial mismatches, unaffected moves, and rejected moves.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

process/needs triage

Is your feature request related to a problem? Please describe.
In our internal field service routing model, we allow users to pin a start service time of a certain visit on an itinerary. This is implemented on a constraint level and allows changes in the planning list variable before the pinned item on the itinerary (provided the pinned start service time still holds), contrary to the pinning the solver currently supports.

Describe the solution you'd like
Some way (maybe an annotation) to specify that a shadow variable on a planning entity is considered pinned and must not change during solving. After evaluation of the shadow variables, the solver could check whether a pinned shadow variable has changed and reject a move before evaluating any constraint.

Alternatively, we could provide a way to specify a predicate as pinned. The value of that predicate would need to stay true after every move.

Considerations (partially discussed with @triceo)

  • We could save two constraints in our internal field service routing model by having solver support for this
  • other uses cases may be opened up by this
    • Example: Reject moves that create unreachable routes in our internal FSR/PDR models
  • This will blur the lines between "real" pinning, where the solver doesn't even touch entities that are pinned and constraints, where the solver would need to evaluate all constraints before making a decision on whether it accepts or rejects a move
  • what happens if the value of the shadow variable is already different from its pinned value in the initial solution?
    • The solver would need to make sure that no moves are rejected that didn't have any influence one the pinned predicate/shadow variable
Lingua principale
Java
Stelle
1.8k
Fork
239
Merge medio
3g 2h
PR unite (30g)
51

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TimefoldAI/timefold-solver

Tutte le issue di TimefoldAI/timefold-solver

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.