Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallel Matches #572

Merged
merged 47 commits into from
May 10, 2016
Merged

Parallel Matches #572

merged 47 commits into from
May 10, 2016

Conversation

marcharper
Copy link
Member

@marcharper marcharper commented May 7, 2016

Re: #520. We'll still need to add a BigResultsSet and to consider breaking out the parallel aspects of the tournament class, but this PR already makes a lot of progress on the memory-consumption front.

Some notes:

  • Memory consumption is vastly reduced while running, however:
  • Large tournaments will still use a lot of memory loading in the resultset~~, which happens automatically at the end~~
  • All results are written to disk (tempfile or supplied filename), tournament no longer has an interactions attribute
  • Caching is done on a match-by-match basis and no longer loaded from a file

Could use some help with the last few tests @drvinceknight .

drvinceknight and others added 22 commits April 27, 2016 08:44
Now a dict mapping index pair to lists.
Mainly with a view to simply the ability to play repetitions of matches
in any order.
(This fixes the doctest making a tournament example.)
This wasn't right because you weren't adding in the players. You do
for the `play_matches` tournament method using `expand`.
Just needed to put the correct inputs in to the work queue.
@drvinceknight
Copy link
Member

Sweet, great job getting this done I'll take a look through it tomorrow! 👍 👏

Could use some help with the last few tests @drvinceknight .

Will sort those out: no problemo :)

@marcharper
Copy link
Member Author

marcharper commented May 8, 2016

Not sure why but test_namespace in test_strategy_transformers.py fails locally yet passes on travis.

drvinceknight and others added 10 commits May 8, 2016 07:18
The failing test confuses me: I assumed this would be what we wanted the
length to be?
Not for master: Adding tutorial, and a test that fails (I think this is the expected behaviour)
Docstrings in:

- match_generator
- tournament
- results_set

Tests: mainly just adding some extra checks for building (or not)
results set.
@drvinceknight
Copy link
Member

I'm pretty happy 👍

I started writing a couple of comments for some remaining things but realised it would be quicker to just open #575. Feel free to consider that a set of comments if you'd rather: it's just some tests and some docstrings that are no longer accurate (I think).

@drvinceknight
Copy link
Member

This is a go from me 👍

PS I think a doctest on the tutorial for making new tournaments might need to be skipped because there is a random situation that will cause a bug (had to rerun a test on my own branch). Just mentioning it in case travis complains (I'm heading to bed).

@marcharper
Copy link
Member Author

Thanks @drvinceknight!

@marcharper
Copy link
Member Author

I think we'll need to use a random number seed to make sure that test always passes.

@drvinceknight
Copy link
Member

I think we'll need to use a random number seed to make sure that test always passes.

Good call: #577

@meatballs
Copy link
Member

If we are no longer passing a cache into the tournament, shouldn't we get rid of the load and save methods on the DeterministicCache class?

@drvinceknight
Copy link
Member

If we are no longer passing a cache into the tournament, shouldn't we get rid of the load and save methods on the DeterministicCache class?

The cache can still be used by a Match and by the MoranProcess so I think it's worth keeping. Always useful for users who might be doing things outside of a tournament?

But the documentation change for using_the_cache.rst here doesn't make that clear (I missed this first time around @marcharper).

I suggest modifying the Caching a Moran Process to something like the following ("First let us..."):

A prebuilt cache can also be used in a Moran process (by default a new cache is used). First let us read in the previously built cache:

>>> cache = axl.DeterministicCache("cache.txt")  #  <- This is a new line, was in the Tournament part
>>> players = [axl.GoByMajority(), axl.Alternator(),
...            axl.Cooperator(), axl.Grudger()]
>>> mp = axl.MoranProcess(players, deterministic_cache=cache)
>>> populations = mp.play()
>>> mp.winning_strategy_name   
Defector

and where it currently says: "Again we see that the cache has been augmented...": that should be "We see that the cache has been augmented...".

@meatballs
Copy link
Member

OK, seems reasonable!

Vince Knight wrote:

If we are no longer passing a cache into the tournament, shouldn't
we get rid of the load and save methods on the DeterministicCache class?

The cache can still be used by a |Match| and by the |MoranProcess| so I
think it's worth keeping. Always useful for users who might be doing
things outside of a tournament?

But the documentation change for |using_the_cache.rst| here doesn't
make that clear (I missed this first time around @marcharper
https://github.com/marcharper).

I suggest modifying the |Caching a Moran Process| to something like the
following ("First let us..."):

|A prebuilt cache can also be used in a Moran process (by default a new cache is used). First let us read in the previously built cache:

cache = axl.DeterministicCache("cache.txt") # <- This is a new line, was in the Tournament part
players = [axl.GoByMajority(), axl.Alternator(),
... axl.Cooperator(), axl.Grudger()]
mp = axl.MoranProcess(players, deterministic_cache=cache)
populations = mp.play()
mp.winning_strategy_name
Defector
|

and where it currently says: "Again we see that the cache has been
augmented...": that should be "We see that the cache has been augmented...".


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#572 (comment)

@marcharper
Copy link
Member Author

The cache on disk may still be useful, here or in other tournament types. I suggest we investigate further after this PR is in. And it could certainly be useful for the Moran process with a lot of types (and that may not be as parallelizable).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants