- 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
hypothesissettings profile for CI
- Restructure the project to use
pyproject.tomlandtox - 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
isortcall in CI. - Minor clean up of
READMEimages.
- Minor docs fixes.
- Update the self-citation information in
paper.bibtov1.3.
- Players are now copied via
copy.deepcopywhen 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
Gameclass withBaseGameand 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.Playerinstances 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
Playerinstances, 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.