Stable preference matching
A locally attractive choice can leave two people wanting to switch. PairCrest is a Windows coding workspace for examining preference algorithms with explicit fixtures and reviewable changes, rather than treating a proposed pairing as a fact about real people.
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- Connection
- Base URL, credentials and a reachable server.
- Project
- Test empty groups and competing choices, rejecting repeated or missing preferences and checking that no blocking pair remains.
- Review before applying
- Compare actual behavior with the expected result. If a check fails, investigate it before applying more changes.
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 partnerMake assignment requirements visible before revising the code
An assignment feature needs more than a list of pairs: it needs a clear account of which inputs are valid and what makes an outcome acceptable. PairCrest provides a Windows AI coding workspace to discuss those requirements with the relevant project files. Start with the preferences your application receives and the constraints it is supposed to respect, then ask for inspection of the current implementation.
The stable-preference example offers one possible development task. You could review how complete rankings are validated, how unmatched work is represented during processing and how the final pairings reach the caller. If your requirements include ties, missing preferences or unequal groups, identify that mismatch before requesting an adaptation. The example's narrower assumptions should remain visible throughout the discussion instead of becoming hidden application policy.
An uncensored AI model may be chosen through a supported OpenAI-compatible or Anthropic endpoint, with credentials when required. The model and server set context, tools and restrictions. Review the proposed input checks and result handling, then test small preference tables with outcomes you can inspect. A separate local model server covers inference only; other tools may still connect to external services.
Clarifying a preference-based feature
What does a useful assignment requirement look like?
Describe the groups, allowed preference forms and property the final assignment should satisfy. Give a small example that people can inspect. Avoid using a broad word such as best without saying how the application should judge an outcome.
Can I add ties without changing the surrounding contract?
Do not assume so. The example expects complete strict preferences. Ties can change both the input representation and the meaning of an acceptable result. Ask for those decisions explicitly before reviewing any proposed algorithm or caller change.
How can I inspect output without a large test dataset?
Start with small preference tables and check the resulting pairs against the stated property. Include invalid rankings to test rejection. These focused cases support review, while the application's own test suite should cover its broader input and integration requirements.
Does PairCrest decide what is fair for the users?
The software workspace does not define your allocation policy. You supply the requirements and assess their consequences. Ask the assistant to explain implementation assumptions, then review whether those assumptions match the rules your application is intended to use.
PairCrest · Updated 2026-10-25