Appariement stable des préférences
Appariez deux groupes d’au plus 20 membres selon des préférences complètes et strictes.
from collections import deque
def stable_pairs(proposers, receivers):
if type(proposers) not in (list, tuple) or type(receivers) not in (list, tuple):
raise ValueError("preference tables must be lists or tuples")
n = len(proposers)
if n > 20 or len(receivers) != n: raise ValueError("equal sizes up to 20")
for rows in (proposers, receivers):
for row in rows:
if type(row) not in (list, tuple) or len(row) != n or any(type(v) is not int for v in row) or set(row) != set(range(n)):
raise ValueError("complete strict preferences")
ranks = [{v:i for i,v in enumerate(row)} for row in receivers]
free, next_choice = deque(range(n)), [0]*n
owner, partner = [None]*n, [None]*n
while free:
p = free.popleft()
r = proposers[p][next_choice[p]]
next_choice[p] += 1
old = owner[r]
if old is None or ranks[r][p] < ranks[r][old]:
owner[r], partner[p] = p, r
if old is not None: partner[old] = None; free.append(old)
else: free.append(p)
return partner- Modèles
- Configurez un endpoint compatible OpenAI ou Anthropic avec son URL de base et une clé API si nécessaire. Testez la connexion. Un serveur local doit fonctionner ; les outils distants peuvent transmettre des données séparément.
- Projet
- Testez les groupes vides et les choix concurrents, en rejetant préférences répétées ou absentes et en vérifiant l’absence de paire bloquante.
- Vérifiez avant d’appliquer
- Comparez le comportement observé au résultat attendu. Si une vérification échoue, cherchez la cause avant de poursuivre les modifications.
from collections import deque
def stable_pairs(proposers, receivers):
if type(proposers) not in (list, tuple) or type(receivers) not in (list, tuple):
raise ValueError("preference tables must be lists or tuples")
n = len(proposers)
if n > 20 or len(receivers) != n: raise ValueError("equal sizes up to 20")
for rows in (proposers, receivers):
for row in rows:
if type(row) not in (list, tuple) or len(row) != n or any(type(v) is not int for v in row) or set(row) != set(range(n)):
raise ValueError("complete strict preferences")
ranks = [{v:i for i,v in enumerate(row)} for row in receivers]
free, next_choice = deque(range(n)), [0]*n
owner, partner = [None]*n, [None]*n
while free:
p = free.popleft()
r = proposers[p][next_choice[p]]
next_choice[p] += 1
old = owner[r]
if old is None or ranks[r][p] < ranks[r][old]:
owner[r], partner[p] = p, r
if old is not None: partner[old] = None; free.append(old)
else: free.append(p)
return partnerExplicitez les exigences d’affectation avant de réviser le code
Une fonction d’affectation demande plus qu’une liste de paires : elle exige une définition claire des entrées valides et des résultats acceptables. PairCrest offre un espace de programmation avec IA sous Windows pour discuter de ces exigences avec les fichiers pertinents du projet. Commencez par les préférences reçues par votre application et les contraintes à respecter, puis demandez un examen de l’implémentation actuelle.
L’exemple d’appariement stable selon les préférences constitue une tâche de développement possible. Vous pouvez examiner la validation des classements complets, la représentation des éléments non appariés pendant le traitement et la transmission des paires finales à l’appelant. Si vos exigences comprennent des ex æquo, des préférences manquantes ou des groupes de tailles différentes, identifiez cet écart avant de demander une adaptation. Les hypothèses plus restreintes de l’exemple doivent rester visibles pendant la discussion plutôt que devenir des règles implicites de l’application.
Un modèle d’IA sans censure peut être choisi via un point de terminaison compatible OpenAI ou Anthropic pris en charge, avec les identifiants requis. Le modèle et le serveur déterminent le contexte, les outils et les restrictions. Examinez les contrôles d’entrée et le traitement des résultats proposés, puis testez de petites tables de préférences dont les résultats sont vérifiables. Un serveur de modèle local distinct ne couvre que l’inférence ; d’autres outils peuvent encore se connecter à des services externes.
Préciser une fonction fondée sur les préférences
À quoi ressemble une exigence d’affectation utile ?
Décrivez les groupes, les formes de préférences autorisées et la propriété que l’affectation finale doit satisfaire. Donnez un petit exemple vérifiable. Évitez un terme général comme meilleur sans préciser comment l’application doit évaluer un résultat.
Puis-je ajouter des ex æquo sans modifier le contrat environnant ?
Ne le présumez pas. L’exemple attend des préférences strictes et complètes. Les ex æquo peuvent changer la représentation des entrées et le sens d’un résultat acceptable. Demandez explicitement ces décisions avant d’examiner une proposition de modification de l’algorithme ou de l’appelant.
Comment examiner la sortie sans grand jeu de données de test ?
Commencez par de petites tables de préférences et vérifiez les paires obtenues au regard de la propriété définie. Incluez des classements invalides pour tester le rejet. Ces cas ciblés facilitent la revue, tandis que la suite de tests de l’application doit couvrir les exigences plus larges d’entrée et d’intégration.
PairCrest décide-t-il de ce qui est équitable pour les utilisateurs ?
L’espace de développement ne définit pas votre politique d’allocation. Vous fournissez les exigences et évaluez leurs conséquences. Demandez à l’assistant d’expliquer les hypothèses d’implémentation, puis vérifiez qu’elles correspondent aux règles que votre application doit appliquer.
PairCrest · Mis à jour 2026-10-25