Fix warnings and update rand #4
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…player. Benefits: * API simplification: the Strategy, Winner, and Evaluator do not need to be passed the current player. * The caller of choose_move cannot move the same player twice in a row. * The Game implementer does not need to worry that a caller or Strategy will feed it bogus Players. * Simplify Evaluator by automatically handling terminal states. Drawbacks: * Game state must keep track of current player.
Benchmark gets 3% slower.
Since nodes that get cut off can return the best score so far (which they know they can't beat), we permute the initial order instead of choosing randomly from the set of equally-performing nodes. The benchmark gets about 2x faster, but individual runs are more variable, as exploring best to worst will cut off a lot more than exploring worst to best. It will always be strictly faster than the previous version.
This serves two purposes: 1) 64 bits seems unnecessary, and 32 bits without an enum tag allows a transposition table to fit more values. 2) A raw i32 allows parallel Strategies to compare and update values with simple atomic operations.
Ensure they evaluate the same result as an optimization-free negamax.
Includes transposition table and timeout.
Negamax isn't going to grow more options. It will remain the basic Strategy with the least trait requirements of a game.
Take the mutable options out of the initial configuration, and prohibit setting max depth and max time at the same time.
Disabled in benchmark as it doesn't help for connect4.
Completely untested because I'm not sure what noisy moves would be in connect four.
This revealed that the principal variation often runs through cutoff nodes, which is concerning...
New unified Game trait * Unifies functions from Game, Move, Zobrist traits. * Unifies game state semantics for mutate-in-place and copy-on-play games. * No useful types need to implement minimax traits, so can you can easily wrap games from other crates.
* Fix wasm build.
Much easier to implement without undo.
It verifies that unweighted rollouts are terrible.
Apparently this simple idea was introduced in a paper called MCTS-Solver, and I don't get their simulation argument so I didn't implement it their way. My way is stupid simple.
* Various MCTS algorithmic improvements. * Verbose mode for MCTS. * Customizable move randomizer for MCTS.
Leads to confusing crashes in MCTS. The hashes were probably not that useful for humans anyway.
* Don't call zobrist_hash from MCTS's verbose mode.
to make it easier to implement games with arbitrarily complex moves where heap alocation is neccessary and therefore the copy trait cannot be easily implemented (if at all)
Removed Copy trait bound on Game::M
No followup interest to bring this to any of the strategies, and I still think games should be heavily encouraged to find ways to make moves super small and cheap. This backs out commit 70dbd40.
Countermoves et al will all be checked first across all threads.
This prevents me being confused when having two util.rs files opened in my editor.
Otherwise high values can stick around several moves after they were relevant.
* Updates to countermoves reordering. * Upgrade rand dependency.
Alternatives considered: I also looked into a few different tiny crates that just do basic RNG with less overhead and cruft. Unfortunately most of them default to a const seed in wasm32-unknown-unknown, so I'd need to do my own getrandom all over the place. Also whatever crate I use will be in the public API of MCTS rollouts, and fancy MCTS rollouts may actually want the fancy distributions that rand provides. While here I sprinkled Send in some places and removed holding on to any ThreadRngs so that all Strategies can be Send types. Switching the rollouts API to SmallRng is technically an API change but any actual usage (do I have users?) will very likely be textually compatible.
feat(stats): iterative deepening statistics table via parallel reads
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.