tansey/pycfr

ENH+DISCUSSION: Rework the testing logic

dohmatob opened this issue · 2 comments

  • Use nosetests: nosetests is the way-to-go for testing python scientific code (and behond)
  • Separate tests and examples: Tests are meant to be short, easy, and run fast (for example, the total running time for all tests run in series can be put under 10 seconds)
  • CI: It be nice to have continuous integration (I'm thinking of travis). This way, PRs can't be merged without fear, etc.
  • assert + near = numpy.testing.assert_array_almost_equal: In general, raw "assert" is strongly discouraged (for example, can't use on production system).

This is only a discussion. Once we're agreed upon these (or any of these) suggestions, I can push code to enforce them.

Most of this seems like overkill for the framework. I would in general like to avoid adding a bunch of package dependencies, since this is not meant to be a production-ready framework.

As for separating tests and examples, that's a bit tricky here. It's hard to test most of the mathematical functions in any non-trivial way without just running a full example like I did. Happy to hear your ideas though.

OK, if some choices were made intentionally (no numpy/scipy, etc.) then I
can live with that.

However, nosetests is not "a bunch of dependencies" . Nobody should write
their own python testing framework with raw "asserts" and "prints" (OK, I
myself have done similar stuff on a number of old one-shot research
projects, but there is simply no way I can defend this nowadays). I'm
pushing some code to address this, and other minor issues (in the ticket
you just closed). If you can't merge it, then I'll have to go my way and
continue minding my own business :)

NB: I'm only interested in the hand-evaluation and game-tree generation
code (this is the core of the business), which I think can be neatly
separated from the CFR stuff.
Credit: The fact that you managed to expose an API as simple as

from pokertrees import *from pokergames import *
players = 2
deck = [Card(14,1),Card(13,2),Card(13,1),Card(12,1)]
rounds = [RoundInfo(holecards=1,boardcards=0,betsize=2,maxbets=[2,2]),RoundInfo(holecards=0,boardcards=1,betsize=4,maxbets=[2,2])]
ante = 1
blinds = [1,2]
gamerules = GameRules(players, deck, rounds, ante, blinds, handeval=leduc_eval)
gametree = GameTree(gamerules)
gametree.build()

for building finite stage-games (poker, etc.) is quite impressive. Gr8
code!

On Tue, Dec 30, 2014 at 2:30 PM, Wesley Tansey notifications@github.com
wrote:

Most of this seems like overkill for the framework. I would in general
like to avoid adding a bunch of package dependencies, since this is not
meant to be a production-ready framework.

As for separating tests and examples, that's a bit tricky here. It's hard
to test most of the mathematical functions in any non-trivial way without
just running a full example like I did. Happy to hear your ideas though.


Reply to this email directly or view it on GitHub
#2 (comment).

DED