- 02 Dec, 2019 2 commits
-
-
Vivien Kraus authored
I don't have that much time
-
Vivien Kraus authored
This kills exploration a little, but it lets us learn from 100% of the games. Otherwise, 4vs1 and 3vs1 games would be ignored most of the time.
-
- 01 Dec, 2019 1 commit
-
-
Vivien Kraus authored
-
- 30 Nov, 2019 1 commit
-
-
Vivien Kraus authored
trump This avoids the following scenario: P1: 4T P2: 21T (I'm the master!) P3: 20T (I'm the master!)
-
- 29 Nov, 2019 26 commits
-
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
This reverts commit d5318d1d.
-
Vivien Kraus authored
-
Vivien Kraus authored
If someone bids a straight keep, there is a 1/2 chance that the next player would bid a double keep. This is not acceptable. This patch reverts this.
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
If I were to use a random perceptron, random bid would be either pass or double keep (because the only feature that would vary would be the strength strategy, which is linear).
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
Of course, when computing the features of a game, we /have/ to look at the game from the perspective of the next player to play, not the player who has been dealt the cards...
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
If I keep the weak initialization, then we won't be able to use 2/3 of the hidden neurons, because the initial weights are cyclic.
-
Vivien Kraus authored
The initial weights are set up so as to predict something between 0 and 1. The score is likely to be between -500 and 500.
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
This algorithm will let us do online machine learning.
-
- 22 Nov, 2019 1 commit
-
-
Vivien Kraus authored
-
- 13 Nov, 2019 2 commits
-
-
Vivien Kraus authored
Resolve "[Packaging] Remove the "safe" target" Closes #177 See merge request !181
-
Vivien Kraus authored
There are some parts of the build system that are recursive. For one, the gnulib layer and the gettext build infrastructure. However, we also need to recursively build the library to generate the binding code, and we need to recursively build all programs in order to get their =--help= output for /help2man/. For these reasons, it is impossible to go without a recursive build system. This poses an unsolved problem. Recursive builds and multi-process builds do not go well together, because each recursive branch does not know what the other branch is touching. So I had created a list of things to get right in that order. Each item of that list could be built with multiple jobs, but the steps had to be taken in order. I had named this list "safe", because it ensured that there would be no recursive call (except the safe target itself that would spawn all tasks). However, this is a little troubling because bootstrapping the project with multiple jobs meant to run =autogen.sh=, then =configure=, then =make safe=, then =make=. I have found that Automake provides /subdirs/, which already implements what I was trying to do. So there is a subdir for each step.
-
- 01 Nov, 2019 7 commits
-
-
Vivien Kraus authored
-
Vivien Kraus authored
=scm_eq_p= returns an SCM, which is a pointer. So we first have to convert to a C-side bool.
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-
Vivien Kraus authored
-