MEA and temere.epd

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

abulmo2
Posts: 433
Joined: Fri Dec 16, 2016 11:04 am
Location: France
Full name: Richard Delorme

Re: MEA and temere.epd

Post by abulmo2 »

Rebel wrote: Sat May 09, 2020 11:37 am I ran Rubichess, 84.xxx positions, 250ms time-bonus=on and time-bonus=off

Code: Select all

    EPD  : epd\ProDeo.epd
    Time : 250ms
                                                       Solving       Max    Total  Time  Hash          
    Engine           Score   Used Time   Found   Pos     Time       Score    Rate   ms    Mb  Cpu CCRL
 1  time-bonus=on   1710890  06:43:40.3  40733  84617  00:19:22.2  2538510  67.4%   250   128  1  3200
 2  time-bonus=off   603229  06:43:40.3  40733  84617  00:19:22.2   846170  71.3%   250   128  1  3200
So, the way I coded things a difference of almost 4% is not noise.

The time bonus is based on the simple observation that Ethereal 12 will find moves much faster than Ethereal 8 because 12 is stronger and thus it should rewarded.
If I understand your table, the result is better without time bonus, so it is doubtful here too.
Maybe the time bonus should only be applied when the best move (from the c0 list) is found, and never on inferior node?
Richard Delorme
User avatar
Rebel
Posts: 6993
Joined: Thu Aug 18, 2011 12:04 pm

Re: MEA and temere.epd

Post by Rebel »

abulmo2 wrote: Sat May 09, 2020 12:08 pm
Rebel wrote: Sat May 09, 2020 11:37 am I ran Rubichess, 84.xxx positions, 250ms time-bonus=on and time-bonus=off

Code: Select all

    EPD  : epd\ProDeo.epd
    Time : 250ms
                                                       Solving       Max    Total  Time  Hash          
    Engine           Score   Used Time   Found   Pos     Time       Score    Rate   ms    Mb  Cpu CCRL
 1  time-bonus=on   1710890  06:43:40.3  40733  84617  00:19:22.2  2538510  67.4%   250   128  1  3200
 2  time-bonus=off   603229  06:43:40.3  40733  84617  00:19:22.2   846170  71.3%   250   128  1  3200
So, the way I coded things a difference of almost 4% is not noise.

The time bonus is based on the simple observation that Ethereal 12 will find moves much faster than Ethereal 8 because 12 is stronger and thus it should rewarded.
If I understand your table, the result is better without time bonus, so it is doubtful here too.
Maybe the time bonus should only be applied when the best move (from the c0 list) is found, and never on inferior node?
The time bonus is about the red.

One can argue about the height of the bonus currently between 0-20 which makes it a different animal than without.
90% of coding is debugging, the other 10% is writing bugs.
User avatar
Rebel
Posts: 6993
Joined: Thu Aug 18, 2011 12:04 pm

Re: MEA and temere.epd

Post by Rebel »

abulmo2 wrote: Sat May 09, 2020 12:03 pm
Rebel wrote: Fri May 08, 2020 7:07 am
abulmo2 wrote: Thu May 07, 2020 2:11 pm I just tested on various Amoeba's versions (1.0 to 3.2 in development), and using my own MEA implementation¹ the impact of time bonus. It seems to just add noise to the score.
Let's check if we are talking about the same. Hypothetical example from the start position:

depth-1 bm Nf3 time 5 ms
depth-2 bm Nf3 time 8 ms
depth-3 bm e4 time 15 ms
depth-4 bm e4 time 25 ms
depth-5 bm d4 time 50 ms
depth-6 bm d4 time 100 ms
depth-7 bm d4 time 200 ms
depth-8 bm e4 time 300 ms
depth-9 bm e4 time 400 ms
depth 10 final move e4 600 ms

For applying a time bonus, which milliesecond value do you use? The blue or the red?
The last blue one.
Just for the record, the "bm" can't be trusted, the EPD'S come from various sources, the MEA moves in "c0" are what matters. And secondly, my experience with sfx sets are better than with the lcx sets.
In my experience, bm moves looked better than the MEA scores with time bonus.
I did again the experiment with sfx-1.epd and get similar results.
Note that Amoeba is a strange beast much better at playing games than at solving positions. Maybe the problem is in my program?
I downloaded Amoeba but noticed it has no tuneable UCI parameters, so I can't test it.

A couple of days ago I ran an eval change with Rubichess, 20,000 positions, 250ms and NICE gave a very positive result. When I ran the same eval change with 84,000 positions the result was equal to the default setting. That was a good lesson, from now on I only test with sfx.epd (80,000 positions).

Currently you can not use more than 8 threads to do the job but in the next version (soon) there is support for 64 threads.
90% of coding is debugging, the other 10% is writing bugs.