I noticed that only 2% of the games could be parsed on my machine. I think this was largely because, in the Italian locale, DecimalFormat uses commas instead of dots. The other important fix is to sort the clauses before randomly selecting the next one. Previously, clause ordering was not guaranteed to be the same across different runs. Now, setting randomSeed to true will produce the same output across different runs.

Hello, I'm currently conducting some experiments on the game Hex using the "Evaluation Dialog" and I noticed that when I allow swap rules, the Player 1 win rate and AdvantageP1 numbers do not match and Balance also doesn't reflect the reported win rates at times. Here is the console output for an experiment on 100 trials, with no timeouts and no draws, using MC-GRAVE AI agent:

Analysing Hex [Board Size/11x11, Swap Rules/On, End Rules/Standard]

Please don't touch anything until complete! Generating trials: .................................................................................................... Calculating metrics: AdvantageP1 Balance Completion Drawishness Timeouts Board Coverage Default Decisiveness Moves Ideal Duration

Agent type: MC-GRAVE Draw likelihood: 0% Timeout likelihood: 0% Average number of moves per game: 30.76 Player 1 win rate: 58% Player 2 win rate: 42%

AdvantageP1: 0.56 (weight: 1.0) Balance: 0.88 (weight: 1.0) Completion: 1 (weight: 1.0) Drawishness: 0 (weight: 1.0) Timeouts: 0 (weight: 1.0) Board Coverage Default: 0.25405 (weight: 1.0) Decisiveness Moves: 0.42 (weight: 1.0) Ideal Duration: 0.43987 (weight: 1.0) Final Score: 3.55391

When I look into EvaluateGame function, the win rate is calculated using "RankUtils.agentUtilities(context);" where it is explicitly checked if players swapped positions, but metrics for Advantage and Balance are calculated using "trial.status().winner()" with no further checks. If the winner is wrongly attributed to a player index before the swap, this would explain this discrepancy.

I'm not that well versed in Java and maybe I overlooked something, but can you please check my findings? The problem is reproducible on Ludii-1.2.8 and a version close to the current master.

Thank you,

David

I noticed that only 2% of the games could be parsed on my machine. I think this was largely because, in the Italian locale, DecimalFormat uses commas instead of dots. The other important fix is to sort the clauses before randomly selecting the next one. Previously, clause ordering was not guaranteed to be the same across different runs. Now, setting randomSeed to true will produce the same output across different runs.

The Dog piece as shown on the English Wikipedia moves to either one of the three forward squares. But it appears the Dog pieces in front of the pawns are either Left Dog or Right Dog, so they will need to be changed to a regular Dog.

• Adapted the POMs to the existing structure.
• Isolate (as far as possible) tests from production code.

Additionally this will enable to add tests with more ease.

Purpose

Remove 143437 white spaces from ludii game files (human linter :) ) in dev

Specifications

Use simple python script:

for ludii_file in ludii_files:
    lud = open(ludii_file, 'r').read()
    n_lud = '\n'.join(line.rstrip() for line in lud.splitlines())
    # append a newline to the end of the file
    n_lud += '\n'
    open(ludii_file, 'w').write(n_lud)

Purpose

Remove 143445 white spaces from ludii game files (human linter :) )

If there's any change you'd like me to make to the script I can easily change it and run it again.

Specifications

Use simple python script:

for ludii_file in ludii_files:
    lud = open(ludii_file, 'r').read()
    n_lud = '\n'.join(line.rstrip() for line in lud.splitlines())
    # append a newline to the end of the file
    n_lud += '\n'
    open(ludii_file, 'w').write(n_lud)