- Fix bug when trying to remove a non-free successor from free residents in HR
- Update link to documentation in README
- Fix sort of murky processing when removing players
- Use a
hypothesis
settings profile for CI
- Restructure the project to use
pyproject.toml
andtox
- Improve the documentation (reformatted doc-strings, migrating to Quarto and GitHub Pages)
- Minor fixes to ensure CI
- Add abstract classes for players, games and matchings.
- Implement extended algorithm for SR, and clean up HR/SM algorithms.
- Move all of the algorithms to their own module,
matching.algorithms
.
- Move unmatching to second phase in SR (allows for simple games.)
- Minor docs fixes.
- Add HR input check for non-positive hospital capacities.
- Remove recursive flag from
isort
call in CI. - Minor clean up of
README
images.
- Minor docs fixes.
- Update the self-citation information in
paper.bib
tov1.3
.
- Players are now copied via
copy.deepcopy
when a game is created and the copies are used, leaving any originals unchanged. - Formalise test and Python requirements in
setup.py
. - Revert flaky forgetting fix from v1.2.1 and correct the flaky tests that were causing the issue.
- Replace the
Game
class withBaseGame
and make it a metaclass viaabc.ABCMeta
. - Fix bugs in documentation stopping build.
- Finish documentation.
- Complete paper for submission to JOSS.
- Catch flaky forgetting bug in
Player
.
- Implement the stable roommates problem.
- Add example tests to all games.
- Flesh out documentation.
- Implemented the student-allocation problem.
- Added capability for large game creation from dictionaries.
- Individuals forget the names of others one at a time rather than all instances at once as previously.
- Add citation file.
- Update travis.yml to stop failures. Dodgy support for Python <3.6.
- Add new badges.
The main changes are as follows:
-
Instead of passing dictionaries to an algorithm function, lists of
matching.Player
instances must be created for the two matching parties. -
Each of these instances have a few attributes but, most importantly, they take a name (this should be unique to the party) and a
list
(ortuple
) ranking their preferences of the names of the other party's members. -
With these lists of
Player
instances, each type of matching game now has its own solver class (e.g. the hospital-resident assignment problem usesmatching.HospitalResident
) with various methods to solve the game and then check the stability/validity of a matching.
Further details given in new README.rst
.
First release. Two main algorithm functions for SM and HR.