Merge branch 'develop'

.gitignore

@@ -1,3 +1,3 @@
 *.o
 *.exe
-.depend
+*.d

Makefile

@@ -1,47 +1,79 @@
 OBJECTS = main.o fileformats/generatorconfiguration.o fileformats/trf.o \
-	matching/computer.o matching/detail/blossom.o matching/detail/graph.o \
-	matching/detail/parentblossom.o matching/detail/rootblossom.o \
-	swisssystems/burstein.o swisssystems/common.o tournament/checker.o \
-	tournament/generator.o tournament/tournament.o
-
-bits = 64
-debug = no
+	matching/computer.o matching/detail/graph.o matching/detail/parentblossom.o \
+	matching/detail/rootblossom.o swisssystems/burstein.o swisssystems/common.o \
+	swisssystems/dutch.o tournament/checker.o tournament/generator.o \
+	tournament/tournament.o
+
+# Flags specifying which Swiss systems to include.
+burstein = yes
+dutch = yes
+
+# Flag indicating whether the tournament checker and random tournament generator
+# should be included
+engine_comparison = yes
+
+# The maximum type sizes that the build should attempt to support.
+# Default values are set/computed in tournament/tournament.h based on the
+# constraints imposed by the TRF(x) format and build limitations.
 max_players = 0
+# Points are specified in tenths. So a value of 999 means that the max total
+# score of a player (with acceleration) is 99.9.
 max_points = 0
 max_rating = 0
 max_rounds = 0
-static = no
+
+bits = 64
+debug = no
+profile = no
 optimize = yes
+static = no
 
-DEPEND_FLAGS += -std=c++14 -I.
-COMPILER_FLAGS += -m$(bits) -Wpedantic -pedantic-errors -Wall -Wextra \
-	-Wuninitialized -Wstrict-overflow=4 -Wundef -Wshadow -Wcast-qual \
-	-Wcast-align -Wmissing-declarations -Wredundant-decls -Wvla \
+COMPILER_FLAGS += -std=c++14 -I. -m$(bits) -MD -MP -Wpedantic -pedantic-errors \
+	-Wall -Wextra -Wuninitialized -Wstrict-overflow=4 -Wundef -Wshadow \
+	-Wcast-qual -Wcast-align -Wmissing-declarations -Wredundant-decls -Wvla \
 	-Wno-unused-parameter -Wno-sign-compare -Wno-maybe-uninitialized -Wno-overflow
 
 VERSION_INFO="$(shell git describe --exact-match 2> /dev/null)"
 ifeq ($(VERSION_INFO),"")
-	VERSION_INFO="non-release build $(shell git describe)"
+	VERSION_INFO="non-release build $(shell git describe 2> /dev/null)"
 endif
 COMPILER_FLAGS += -DVERSION_INFO=$(VERSION_INFO)
 
 ifeq ($(static),yes)
 	LDFLAGS += -static
 endif
 
-ifeq ($(debug),yes)
-	COMPILER_FLAGS += -g
-	ifeq ($(optimize),yes)
-		CXXFLAGS += -Og
+ifeq ($(profile),yes)
+	COMPILER_FLAGS += -ggdb
+	CXXFLAGS += -O3
+	ifneq ($(debug),yes)
+		COMPILER_FLAGS += -DNDEBUG
 	endif
 else
-	COMPILER_FLAGS += -DNDEBUG
-	LDFLAGS += -s
-	ifeq ($(optimize),yes)
-		CXXFLAGS += -O3
+	ifeq ($(debug),yes)
+		COMPILER_FLAGS += -ggdb
+		ifeq ($(optimize),yes)
+			CXXFLAGS += -Og
+		endif
+	else
+		COMPILER_FLAGS += -DNDEBUG
+		LDFLAGS += -s
+		ifeq ($(optimize),yes)
+			CXXFLAGS += -O3
+		endif
 	endif
 endif
 
+ifneq ($(burstein),yes)
+	COMPILER_FLAGS += -DOMIT_BURSTEIN
+endif
+ifneq ($(dutch),yes)
+	COMPILER_FLAGS += -DOMIT_DUTCH
+endif
+ifneq ($(engine_comparison),yes)
+	COMPILER_FLAGS += -DOMIT_GENERATOR -DOMIT_CHECKER
+endif
+
 ifneq ($(max_players),0)
 	COMPILER_FLAGS += -DMAX_PLAYERS=$(max_players)
 endif
@@ -55,8 +87,6 @@ ifneq ($(max_rounds),0)
 	COMPILER_FLAGS += -DMAX_ROUNDS=$(max_rounds)
 endif
 
-COMPILER_FLAGS += $(DEPEND_FLAGS)
-
 ifeq ($(COMP),)
 	COMP=gcc
 endif
@@ -65,45 +95,46 @@ ifeq ($(COMP),gcc)
 	COMPILER_FLAGS += -Wdouble-promotion -Wsuggest-final-types \
 		-Wsuggest-final-methods -Wsuggest-override -Warray-bounds=2 \
 		-Wduplicated-cond -Wtrampolines -Wconditionally-supported \
-		-Wzero-as-null-pointer-constant -Wlogical-op \
-		-Wno-aggressive-loop-optimizations -Wvector-operation-performance
+		-Wlogical-op -Wno-aggressive-loop-optimizations \
+		-Wvector-operation-performance
 
 	ifeq ($(HOST),Windows)
-		CXX=x86_64-w64-mingw32-g++
-		UNOPTIMIZED_FLAGS = $(COMPILER_FLAGS)
+		ifeq ($(bits),32)
+			CXX=i686-w64-mingw32-g++
+		else
+			CXX=x86_64-w64-mingw32-g++
+		endif
+		ifeq ($(optimize),yes)
+			COMPILER_FLAGS += -flto
+		endif
 		CXXFLAGS += $(COMPILER_FLAGS)
 	else
 		CXX=g++
-		COMPILER_FLAGS += -DEXPERIMENTAL_FILESYSTEM
+		CXXFLAGS += $(COMPILER_FLAGS)
+		CXXFLAGS += -DEXPERIMENTAL_FILESYSTEM
 		ifeq ($(optimize),yes)
 			CXXFLAGS += -flto
 		endif
 		LDFLAGS += -lstdc++fs
-		CXXFLAGS += $(COMPILER_FLAGS)
-		UNOPTIMIZED_FLAGS = $(CXXFLAGS)
 	endif
 endif
 
 LDFLAGS += $(CXXFLAGS)
 
 .PHONY: build clean
-build: bbpPairings.exe .depend
+build: bbpPairings.exe
+
+makefile_directory:=$(dir $(abspath $(lastword $(MAKEFILE_LIST))))
 
 clean:
-	$(RM) bbpPairings.exe .dep.inc .depend
-	find . -name \*.o -type f -delete
+	$(RM) bbpPairings.exe
+	find $(makefile_directory) -name \*.o -type f -delete
+	find $(makefile_directory) -name \*.d -type f -delete
 
 default:
 	build
 
 bbpPairings.exe: $(OBJECTS)
 	$(CXX) -o $@ $(OBJECTS) $(LDFLAGS)
 
-.depend:
-	-@$(CXX) $(DEPEND_FLAGS) -MM $(OBJECTS:.o=.cpp) > $@
-
-# A bug in mingw-w64 causes compilation of tournament/generator.o with
-# optimization to fail.
-tournament/generator.o: CXXFLAGS := $(UNOPTIMIZED_FLAGS)
-
--include .depend
+-include $(OBJECTS:%.o=%.d)

README.txt

@@ -4,7 +4,7 @@ copyright (C) 2016
 See LICENSE.txt for additional copyright and licensing information.
 
 The most recent version of this program can be downloaded at
-https://github.com/BieremaBoyzProgramming/bbpPairings/releases .
+<https://github.com/BieremaBoyzProgramming/bbpPairings/releases>.
 
 
 BBP Pairings is an engine for pairing players in a Swiss-system chess
@@ -13,19 +13,19 @@ Pairings and Program Commission. To be clear, the program is not endorsed by
 FIDE or the SPP. It is not a full tournament manager, just an engine for
 computing the pairings.
 
-The program currently implements only the Burstein system.
+The program currently implements the Burstein system and the 2017 Dutch rules.
 
 The program's interface is designed to be very similar to that described in the
 advanced user manual for JaVaFo 1.4 (with permission to do so from the author,
 Roberto Ricca). The remainder of this document lists the points of divergence.
-For more informaton about JaVaFo, please visit www.rrweb.org/javafo . This
+For more informaton about JaVaFo, please visit <www.rrweb.org/javafo>. This
 documentation assumes full understanding of the JaVaFo AUM.
 
 Hereafter, we will use the name "JaVaFo" to refer to JaVaFo 1.4.
 
-TRF(xb)
+TRF(bx)
 -------
-BBP Pairings supports only one file format, TRF(xb), an extension of the TRF(x)
+BBP Pairings supports only one file format, TRF(bx), an extension of the TRF(x)
 format defined for JaVaFo.
 
 JaVaFo attempts to infer the point system used for the tournament (the number of
@@ -42,41 +42,54 @@ scores are adjusted by counting unplayed games as draws when calculating their
 opponents' tiebreak scores, the program needs to know the number of points given
 for draws and cannot infer it.
 
-For this reason, we must introduce an extension to the TRF(xb) format. The
-extension uses codes BBW and BBD for specifying the number of points awarded for
-a win and a draw, respectively. The format is
+For this reason, we must introduce an extension to the TRF(bx) format. The
+extension uses codes BBW, BBD, BBL, BBZ, BBF, and BBU for specifying the number
+of points awarded for a win, draw, played loss, zero-point bye, forfeit loss, or
+pairing-allocated bye, respectively. The format is
 BBW pp.p
 BBD pp.p
-Thus, for a tournament with 3 points for wins and 1 point for draws, the TRF(xb)
+...
+Thus, for a tournament with 3 points for wins and 1 point for draws, the TRF(bx)
 should contain the lines
 BBW  3.0
 BBD  1.0
+If BBU is not specified, it defaults to the score for a win. All other
+parameters default individually to particular values (1.0, 0.5, or 0.0) if not
+specified.
 
-If the tournament uses the standard point system (as of the 2014 rules), that
-is, 1 point for wins and 0.5 points for draws, these lines are not necessary.
+If the tournament uses the standard point system (as of the 2014 rules), these
+lines are not necessary.
 
 Because this requirement causes an incompatibility with the TRF(x)
 representation of non-standard point system tournaments that could be overlooked
 when exchanging files, BBP Pairings checks that all players' scores are computed
 correctly from the tournament results. If this is not the case, it issues an
 error message and refuses to proceed.
 
-Future versions may relax the strict requirement to permit point systems that
-are linear multiples of the standard system, such as the 2-1-0 point system
-currently being discussed.
+The engine for the Burstein system expects the point value for pairing-allocated
+byes to equal one of the other point value parameters when computing virtual
+opponent scores for the Buchholz and Sonneborn-Berger scores. If this is not the
+case, it approximates the pairing-allocated bye point value as a win, loss, or
+draw (rounding down), only for the purposes of choosing the virtual opponent
+score for the round. In an unplayed game counted as a win, the forfeit loss
+score is currently used as the the virtual opponent score, not the played loss.
+These behaviors may change in future versions if criticized.
 
 
 BBP Pairings does not support random selection of the initial piece color. The
 initial piece color must be specified when generating the pairings for the first
 round of the tournament (or more precisely, any round of the tournament in which
 no player has previously been assigned a color).
 
-If not specified, the initial piece color is assumed to be the color of the
-highest player in the first round, where by "first round" we again mean the
-first round where a color was assigned, and by "highest player" we mean the
-player with the smallest pairing ID out of the players who were assigned a color
-in the "first round." However, if the rank configuration option is applied,
-positional IDs are used instead of pairing IDs.
+Let Round F refer to the first round where a color assignment is listed in the
+TRF(xb) for a certain tournament. If the initial piece color of the tournament
+is not specified, it is assumed to be the Round-F color of the highest player
+who participated in the pairing of Round F or an earlier round (where "highest
+player" is defined by pairing IDs or positional IDs, depending on whether the
+"rank" configuration option is used). If this highest player does not have a
+color listed for Round F, we use the Round-F color of the second highest player
+who participated in the pairing of Round F or earlier, but reverse the color,
+and so on.
 
 Note that if pairing numbers are reordered after pairing the first round, the
 inferred initial color might not be correct, and the correct initial color
@@ -88,8 +101,13 @@ TRF, but it can also read files produced using the codes specified in the JaVaFo
 AUM.
 
 
-Generator
----------
+Random Tournament Generator
+---------------------------
+The point value parameters not supported in JaVaFo 1.4 can be set using the keys
+PointsForLoss, PointsForZPB, PointsForForfeitLoss, and PointsForPAB. All of
+these have default values of 0.0, except the last, which by default is set equal
+to PointsForWin.
+
 BBP Pairings introduces a new option for generating tournaments paired using the
 Burstein system. Since the Burstein system has a specific acceleration system
 included in its rules, the "Accelerated" option instructs the generator to apply
@@ -123,6 +141,11 @@ games. The "Buchholz score" is the product of the player's total score and her
 in different scoregroups (again, assuming their SB scores are the same). The
 "Median tiebreak" and "Median score" are defined analogously.
 
+For the Dutch system, the column C2 indicates whether a given player is eligible
+for the pairing-allocated bye (Y if yes, N if no). The C12 and C14 columns
+indicate the floating direction of the player on the previous and
+next-to-previous rounds, respectively (U for upfloat, D for downfloat).
+
 BBP Pairing has the additional option to generate checklist files while
 generating or checking tournaments, not just when pairing individual rounds. In
 this case, the tables for all of the rounds are put into the same file, with
@@ -133,9 +156,8 @@ Command line arguments
 BBP Pairings always performs pairings using a weighted matching algorithm, so it
 does not use the -w and -q options of JaVaFo.
 
-Since BBP Pairings has been designed with the intention of supporting more than
-one Swiss system in the future, an argument specifying which Swiss system to use
-for pairing is required.
+Since BBP Pairings supports more than one Swiss system, an argument specifying
+which Swiss system to use for pairing is required.
 
 For the most part, BBP Pairings was written to be compatible with compilers
 supporting the 2014 C++ standard (C++14). However, C++14 has no portable way to
@@ -153,9 +175,9 @@ version information displayed when using the -r flag.
 
 The acceptable syntax forms for running BBP Pairings are:
 bbpPairings.exe [-r]
-bbpPairings.exe [-r] --burstein input-file -c [-l check-list-file]
-bbpPairings.exe [-r] --burstein input-file -p [output-file] [-l check-list-file]
-bbpPairings.exe [-r] --burstein (model-file -g | -g [config-file]) -o trf_file [-s random_seed] [-l check-list-file]
+bbpPairings.exe [-r] (--burstein | --dutch) input-file -c [-l check-list-file]
+bbpPairings.exe [-r] (--burstein | --dutch) input-file -p [output-file] [-l check-list-file]
+bbpPairings.exe [-r] (--burstein | --dutch) (model-file -g | -g [config-file]) -o trf_file [-s random_seed] [-l check-list-file]
 
 On a build of BBP Pairings that supports file path manipulation capabilities,
 the check-list-file argument is optional, with the same default as JaVaFo. If no
@@ -173,25 +195,44 @@ Error codes
 When the program encounters an error, it usually prints a message describing the
 error to the standard error stream. (As an exception, an error while generating
 a checklist file may be written to the checklist file itself and not reported
-elsewhere). The program also returns error codes that a calling program can use
-to categorize the cause of the error. The following codes are used in the
-following situations:
+elsewhere.) If the program does not complete its main operation because of an
+error, the program also returns error codes that a calling program can use to
+categorize the cause of the error. The following codes are used in the following
+situations:
 0: The program completed successfully.
 1: The operation could not be completed because no valid pairing exists for the
-   current round of the tournament. (This error code is not used when checking a
-   tournament; instead, a message is included in the list of discrepancies.)
+   current round of the tournament. (This is not considered an error when
+   checking a tournament; instead, a message is included in the list of
+   discrepancies.)
 2: The program encountered an unexpected error.
 3: Some part of the request was invalid, for example, a wrongly formatted input
    file.
 4: The request may be valid, but the size of the data could not be handled by
    the program, either because it ran out of memory or due to size constraints
-   specified at compile time or imposed by the compiler.
+   specified at compile time or imposed by the compiler. (This error code is not
+   triggered during checklist generation.)
 5: There was an error while attempting to access a file; for example, the input
-   file might not exist or might not be readable.
+   file might not exist or might not be readable. (This error code is not
+   triggered for checklist files.)
 
 Time complexity
 ---------------
-Let n denote the largest player ID in a given tournament. Assuming the number of
-rounds in the tournament is O(n), this program is believed to achieve a
-theoretic runtime that is O(n^3) for pairing a single round using the Burstein
-system.
+Let n denote the largest player ID in a given tournament and r the number of
+rounds already played. For simplicity, assume r is O(n).
+
+This program is believed to achieve a theoretic runtime that is O(n^3) for
+pairing a single round using the Burstein system.
+
+For the Dutch system, pairing a round is believed to take time
+O(n^3 * s * (d + s) * log n), where s is the number of occupied score groups
+in the current round and d is the number of distinct score differences between
+two players in the round. Note that if the point system (the number of points
+for wins and for draws) is treated as constant and there is no acceleration,
+then d and s are both O(r), since the point values are rational numbers, and in
+that case, the runtime is O(n^3 * r^2 * log n). If we also assume that r is
+O(log n), then the runtime is O(n^3 * (log n)^3).
+
+The core of the pairing engine is an application of the simpler of the two
+weighted matching algorithms exposited in "An O(EV log V) Algorithm for Finding
+a Maximal Weighted Matching in General Graphs," by Zvi Galil, Silvio Micali, and
+Harold Gabow, 1986.