Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
Faster testing ?
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 4606
- Joined: Wed Oct 01, 2008 6:33 am
- Location: Regensburg, Germany
- Full name: Guenther Simon
Re: Faster testing ?
This is already pretty good:xr_a_y wrote: ↑Thu Aug 15, 2019 1:07 pm Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
http://www.fastgm.de/60-0.60.html
Minic is missing though, but not for long I guess ;-)
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Faster testing ?
Oh thanks, I did forgot this one. One thing anyway is that I prefer "N moves in M minutes" rather than sudden-death even with increment but this is mainly because I don't really know how to handle it properlyGuenther wrote: ↑Thu Aug 15, 2019 1:50 pmThis is already pretty good:xr_a_y wrote: ↑Thu Aug 15, 2019 1:07 pm Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
http://www.fastgm.de/60-0.60.html
Minic is missing though, but not for long I guess
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: Faster testing ?
N moves in M minutes is an obsolete and extremely wasteful way to test. It is no longer used in human chess as far as I know (for one or two time controls, yes, but always with a sudden death time control at the end), and for engine testing it is a terrible waste of resources to play out hopelessly drawn endgames for hundreds of moves at the same pace as the part of the game where the result is being decided. I know that that CCRL and CEGT still use it to maintain historical connection to the old machines which were tested before increment became normal, but they could switch to increment tc averaging the same time for 60 moves and combine the data without much risk of distortion, reverting to 40/x for old engines that did not support increment.xr_a_y wrote: ↑Thu Aug 15, 2019 2:34 pmOh thanks, I did forgot this one. One thing anyway is that I prefer "N moves in M minutes" rather than sudden-death even with increment but this is mainly because I don't really know how to handle it properlyGuenther wrote: ↑Thu Aug 15, 2019 1:50 pmThis is already pretty good:xr_a_y wrote: ↑Thu Aug 15, 2019 1:07 pm Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
http://www.fastgm.de/60-0.60.html
Minic is missing though, but not for long I guess
Komodo rules!
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Faster testing ?
Draws can be decided by end game table or by a specific rules, no need to let the engines plays hundred of moves. Mean Ccrl game length is quite correct i think. Is that the only argument against this kind of TC?lkaufman wrote: ↑Thu Aug 15, 2019 6:18 pmN moves in M minutes is an obsolete and extremely wasteful way to test. It is no longer used in human chess as far as I know (for one or two time controls, yes, but always with a sudden death time control at the end), and for engine testing it is a terrible waste of resources to play out hopelessly drawn endgames for hundreds of moves at the same pace as the part of the game where the result is being decided. I know that that CCRL and CEGT still use it to maintain historical connection to the old machines which were tested before increment became normal, but they could switch to increment tc averaging the same time for 60 moves and combine the data without much risk of distortion, reverting to 40/x for old engines that did not support increment.xr_a_y wrote: ↑Thu Aug 15, 2019 2:34 pmOh thanks, I did forgot this one. One thing anyway is that I prefer "N moves in M minutes" rather than sudden-death even with increment but this is mainly because I don't really know how to handle it properlyGuenther wrote: ↑Thu Aug 15, 2019 1:50 pmThis is already pretty good:xr_a_y wrote: ↑Thu Aug 15, 2019 1:07 pm Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
http://www.fastgm.de/60-0.60.html
Minic is missing though, but not for long I guess
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: Faster testing ?
Tablebases only help when the number of men is 7 or less; there are plenty of clearly drawn endgames with more than 7 men, and often one side is "better" so no adjudication rule makes much sense. For example bishops of opposite color with four pawns vs. three but obviously no way to progress. The more general argument is that the chance of a move deciding the game is much smaller at move 100 than at move 30 so allocating the same amount of time per move just doesn't make sense. Increment handles this in a pretty good way. Full disclosure: I'm not neutral on this, as I am on record as the inventor of the use of increment for chess (despite Bobby Fischer's claims to same).xr_a_y wrote: ↑Thu Aug 15, 2019 7:22 pmDraws can be decided by end game table or by a specific rules, no need to let the engines plays hundred of moves. Mean Ccrl game length is quite correct i think. Is that the only argument against this kind of TC?lkaufman wrote: ↑Thu Aug 15, 2019 6:18 pmN moves in M minutes is an obsolete and extremely wasteful way to test. It is no longer used in human chess as far as I know (for one or two time controls, yes, but always with a sudden death time control at the end), and for engine testing it is a terrible waste of resources to play out hopelessly drawn endgames for hundreds of moves at the same pace as the part of the game where the result is being decided. I know that that CCRL and CEGT still use it to maintain historical connection to the old machines which were tested before increment became normal, but they could switch to increment tc averaging the same time for 60 moves and combine the data without much risk of distortion, reverting to 40/x for old engines that did not support increment.xr_a_y wrote: ↑Thu Aug 15, 2019 2:34 pmOh thanks, I did forgot this one. One thing anyway is that I prefer "N moves in M minutes" rather than sudden-death even with increment but this is mainly because I don't really know how to handle it properlyGuenther wrote: ↑Thu Aug 15, 2019 1:50 pmThis is already pretty good:xr_a_y wrote: ↑Thu Aug 15, 2019 1:07 pm Is there some interest in faster testing (ultra-bullet style)? something that would be like a CCRL 40/1 scale (meaning 4 times faster than CCRL 40/4, so around 20sec or 15sec on recent hardware).
It would be quite cheap testing and a database can be built pretty quickly.
http://www.fastgm.de/60-0.60.html
Minic is missing though, but not for long I guess
Komodo rules!
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Faster testing ?
Ok I get your point but i'd be curious to see some stats on the subject (match lenght, tpye of draws...).
Sudden-death matches can also suffer from blunder in end game or failure to find a mate sequence being too short on time and living on a small increment...
I guess I shall work on sudden death + incr in Minic anyway...
Sudden-death matches can also suffer from blunder in end game or failure to find a mate sequence being too short on time and living on a small increment...
I guess I shall work on sudden death + incr in Minic anyway...
-
- Posts: 5960
- Joined: Sun Jan 10, 2010 6:15 am
- Location: Maryland USA
Re: Faster testing ?
As long as the base to increment ratio is reasonable, there should be no more risk of making bad moves in the endgame than in the middlegame, since on average you get a lot more depth in the endgame in the same time, and also because the chance of the result still being in doubt is lower. Rating lists seem to have settled on 100 to 1 for the ratio, while tournaments like CCC and TCEC usually use larger ratios, close to the 180 or 240 ratios typical of human GM events. We mostly use 150 to 1 ratio as a compromise between these ratios in our own testing.xr_a_y wrote: ↑Thu Aug 15, 2019 7:59 pm Ok I get your point but i'd be curious to see some stats on the subject (match lenght, tpye of draws...).
Sudden-death matches can also suffer from blunder in end game or failure to find a mate sequence being too short on time and living on a small increment...
I guess I shall work on sudden death + incr in Minic anyway...
Komodo rules!
-
- Posts: 2727
- Joined: Wed May 12, 2010 10:00 pm
Re: Faster testing ?
I see more human tournaments using delay. When playing at fast time controls. Is this something that will be implemented in computer chess?lkaufman wrote: ↑Thu Aug 15, 2019 10:58 pmAs long as the base to increment ratio is reasonable, there should be no more risk of making bad moves in the endgame than in the middlegame, since on average you get a lot more depth in the endgame in the same time, and also because the chance of the result still being in doubt is lower. Rating lists seem to have settled on 100 to 1 for the ratio, while tournaments like CCC and TCEC usually use larger ratios, close to the 180 or 240 ratios typical of human GM events. We mostly use 150 to 1 ratio as a compromise between these ratios in our own testing.xr_a_y wrote: ↑Thu Aug 15, 2019 7:59 pm Ok I get your point but i'd be curious to see some stats on the subject (match lenght, tpye of draws...).
Sudden-death matches can also suffer from blunder in end game or failure to find a mate sequence being too short on time and living on a small increment...
I guess I shall work on sudden death + incr in Minic anyway...
"The worst thing that can happen to a forum is a running wild attacking moderator(HGM) who is not corrected by the community." - Ed Schröder
But my words like silent raindrops fell. And echoed in the wells of silence.
But my words like silent raindrops fell. And echoed in the wells of silence.
-
- Posts: 476
- Joined: Sun Mar 17, 2019 12:00 pm
- Full name: Henk Drost
Re: Faster testing ?
No need to implement delay for computers since they don't have a reaction time like humans, and a computer moves pieces at instant speed.mwyoung wrote: ↑Fri Aug 16, 2019 6:17 amI see more human tournaments using delay. When playing at fast time controls. Is this something that will be implemented in computer chess?lkaufman wrote: ↑Thu Aug 15, 2019 10:58 pmAs long as the base to increment ratio is reasonable, there should be no more risk of making bad moves in the endgame than in the middlegame, since on average you get a lot more depth in the endgame in the same time, and also because the chance of the result still being in doubt is lower. Rating lists seem to have settled on 100 to 1 for the ratio, while tournaments like CCC and TCEC usually use larger ratios, close to the 180 or 240 ratios typical of human GM events. We mostly use 150 to 1 ratio as a compromise between these ratios in our own testing.xr_a_y wrote: ↑Thu Aug 15, 2019 7:59 pm Ok I get your point but i'd be curious to see some stats on the subject (match lenght, tpye of draws...).
Sudden-death matches can also suffer from blunder in end game or failure to find a mate sequence being too short on time and living on a small increment...
I guess I shall work on sudden death + incr in Minic anyway...