This week's lecture focused on devising tests for assignment 2 and getting started with assignment 3. I have not carefully thought about assignment 3 yet, but I think optimizing minimax is a neat option because right now it takes too long for minimax to suggest a move for most game states. As the author whose post is at http://1024forbidden.blogspot.ca/2015/03/week10-start-of-a3-and.html feels, minimax seems to be stuck forever when starting on a 4 by 4 tippy grid. To put it bluntly, it is useless to provide the best possible move when it takes too long to do so. Then, swapping out the meticulousness for some much needed efficiency would be a wise choice.
This week's lab activity also covers testing functions and methods with unit tests. One issue I had with testing strategy minimax on subtract square is that it can get strenuous when trying to find good numbers that has few winning moves and many losing moves, because I have to trace through every number and find out whether it is a winning position or a losing position. However, I wonder how much credibility my code would give if, instead of devising new test cases, I just run the test module multiple times, with no exception raised. If the starter code provides test cases where 1 in 625 random responses can pass, then perhaps rerunning the test cases can give a 1 in 625^2 chance of a random response passing? I don't see a flaw in this logic and, the chance of a random response passing would decrease exponentially, much faster than trying to figure out other suitable test cases. Unless, the code being tested only returns that one series of response which is acknowledged by the tests, in which case devising new cases would detect the problem at once.
No comments:
Post a Comment