Singular Extensions

[Daniel Shawul]

It was meant for Ralph who implied stockfish would gain more from it with time. I do not believe so.

But anyway why would you think it would help more at longer TC. CEGT ranking says otherwise for Komodo

40/4

Code: Select all

Komodo 1.2 x64 1CPU 	3007 	15 	15 	1198 	54.8% 	2974 	41.7%

40/20

Code: Select all

Komodo 1.2 x64 	3004 	17 	17 	898 	48.7% 	3013 	46.8%

[Don]

It was meant for Ralph who implied stockfish would gain more from it with time. I do not believe so.

But anyway why would you think it would help more at longer TC. CEGT ranking says otherwise for Komodo

40/4

Code: Select all

Komodo 1.2 x64 1CPU 	3007 	15 	15 	1198 	54.8% 	2974 	41.7%

40/20

Code: Select all

Komodo 1.2 x64 	3004 	17 	17 	898 	48.7% 	3013 	46.8%

Komodo has scores of ideas in it, so you cannot isolate just one of them and claim it's responsible for a given result. To do this we would need to test Komodo with and without SE.

But I don't actually have a strong opinion on this, I know I could very well be wrong. But I do have at least a (weak) rationale for thinking so. It is based on my own notion that anything that intelligently improves selectivity should improve the programs scalability. For example if you can reliably prune (or reduce) more moves, your program will benefit more with time. A "correct" extension to me can be cast as a scalability improvement, it's sort of like reducing all moves except the extended one.

Of course the issue is doing these things in the proper proportions. You cannot reduce everything that is "probably" bad by too much and neither can you extend things that are probably good without regard to the rest of the tree.

[Daniel Shawul]

Komodo has scores of ideas in it, so you cannot isolate just one of them and claim it's responsible for a given result. To do this we would need to test Komodo with and without SE.

But I don't actually have a strong opinion on this, I know I could very well be wrong. But I do have at least a (weak) rationale for thinking so. It is based on my own notion that anything that intelligently improves selectivity should improve the programs scalability. For example if you can reliably prune (or reduce) more moves, your program will benefit more with time. A "correct" extension to me can be cast as a scalability improvement, it's sort of like reducing all moves except the extended one.

If the SE is actually improving it, other things must be slowing it down, for the overall effect to be neutral
as such. I do not think so. _Especially_ not with extensions. They have been very successful in the past when
the depths were limited. When we start getting reasonable depth, they all went out of the window.
I barely use the check extension nowadays. Many times here we have ideas which supposedly work at longer TC but foundout otherwise. Before CEGT came here
I was actually one of those believers.

For selectivity, I believe that as long as there is no obvious flow in short TC tests (like not getting enough input by using too large depthleft parameters), what you get in the long run is what you see at short tc.
The scalability of SMP,LMR and many other things have been discussed here before.. Bob can say more on this.

[mcostalba]

CEGT List

40/4

Code: Select all

Stockfish 1.8 x64 1CPU 	3128 	16 	16 	1300 	67.0% 	3005 	35.6%
Stockfish 1.7.1 x64 1CPU 	3099 	11 	11 	2340 	62.0% 	3014 	36.2%

40/20

Code: Select all

Stockfish 1.8 x64 1CPU 	3090 	20 	20 	650 	62.8% 	2999 	45.8%
Stockfish 1.7.1 x64 1CPU 	3084 	17 	17 	875 	61.6% 	3002 	47.8%

I don't know if the same base is used for the lists , but if it was then infact stockfish seems stronger in blitz not longer tc. Even if that was not the case, the relative ranking almost remains the same.
So the singular extensions or anything else for that matter is not suddenly giving it a push.

In case you are interested SF introduced SE in 1.6

Changes between 1.7.1 and 1.8 have nothing to do with SE.

[Don]

Komodo has scores of ideas in it, so you cannot isolate just one of them and claim it's responsible for a given result. To do this we would need to test Komodo with and without SE.

But I don't actually have a strong opinion on this, I know I could very well be wrong. But I do have at least a (weak) rationale for thinking so. It is based on my own notion that anything that intelligently improves selectivity should improve the programs scalability. For example if you can reliably prune (or reduce) more moves, your program will benefit more with time. A "correct" extension to me can be cast as a scalability improvement, it's sort of like reducing all moves except the extended one.

If the SE is actually improving it, other things must be slowing it down, for the overall effect to be neutral
as such.

And it's almost certainly the case that this is the case. There are surely some things in Komodo that do not scale well with long time controls. Things I cannot easily test.

So there is no simple way to pin down the affect SE has on this, other than for me to run tens of thousands of games at both long and short time controls with 2 different versions of my program.

I do not think so. _Especially_ not with extensions. They have been very successful in the past when
the depths were limited. When we start getting reasonable depth, they all went out of the window.
I barely use the check extension nowadays. Many times here we have ideas which supposedly work at longer TC but foundout otherwise. Before CEGT came here
I was actually one of those believers.

For selectivity, I believe that as long as there is no obvious flow in short TC tests (like not getting enough input by using too large depthleft parameters), what you get in the long run is what you see at short tc.
The scalability of SMP,LMR and many other things have been discussed here before.. Bob can say more on this.

[Don]

Komodo has scores of ideas in it, so you cannot isolate just one of them and claim it's responsible for a given result. To do this we would need to test Komodo with and without SE.

But I don't actually have a strong opinion on this, I know I could very well be wrong. But I do have at least a (weak) rationale for thinking so. It is based on my own notion that anything that intelligently improves selectivity should improve the programs scalability. For example if you can reliably prune (or reduce) more moves, your program will benefit more with time. A "correct" extension to me can be cast as a scalability improvement, it's sort of like reducing all moves except the extended one.

If the SE is actually improving it, other things must be slowing it down, for the overall effect to be neutral
as such.

And it's almost certainly the case that this is happening. There are surely some things in Komodo that do not scale well with long time controls. Things I cannot easily test.

So there is no simple way to pin down the affect SE has on this, other than for me to run tens of thousands of games at both long and short time controls with 2 different versions of my program.

I do not think so. _Especially_ not with extensions. They have been very successful in the past when
the depths were limited. When we start getting reasonable depth, they all went out of the window.
I barely use the check extension nowadays. Many times here we have ideas which supposedly work at longer TC but foundout otherwise. Before CEGT came here
I was actually one of those believers.

For selectivity, I believe that as long as there is no obvious flow in short TC tests (like not getting enough input by using too large depthleft parameters), what you get in the long run is what you see at short tc.
The scalability of SMP,LMR and many other things have been discussed here before.. Bob can say more on this.

[Daniel Shawul]

Duh I am _not_ comapring 1.7.1 and 1.8.
The point is Stockfish 1.7 or 1.8 both has SE and their blitz or long time rating yet remains the same.
If it gave it a push we should see its benefits there too, no ?

[Don]

Duh I am _not_ comapring 1.7.1 and 1.8.
The point is Stockfish 1.7 or 1.8 both has SE and their blitz or long time rating yet remains the same. If it gave it a push we should see its benefits there too, no ?

No. If SF gets the same rating at both short and long time controls, why is it you think you can pick out one thing (such as SE) and claim that this is proof that SE does not help or hurt it at long time controls?

It could be (and almost certainly is the case) that some things in SF scale better than others. They have the same trouble everyone else does, it's very difficult to get a lot of games in at long time controls.

So some of the things in SF probably help the program even more at longer time controls and some things help less, or even hurt it at longer time controls.

The fact that it does not get weaker or stronger at long time controls means that on average they balance out. It doesn't mean you can pick a feature at random and say this proves that feature does not help or hurt at long time controls.

[Daniel Shawul]

Latest version i can get in both lists without SE.

40/4

Code: Select all

96 	Stockfish 1.5.1 JA w32 2CPU 	2973 	14 	14 	1600 	60.1% 	2902 	33.3%

40/20

Code: Select all

71 	Stockfish 1.5.1 x64 2CPU 	2980 	17 	17 	904 	53.4% 	2956 	42.5%

So with SE or without SE, the trend remains the same... Blitz and long tc ratings are more or less the same. So what is it now ? The SE is gone ...

[Daniel Shawul]

For Doch probably without SE (that is first version)

40/4

Code: Select all

208 	Doch 09.980 x64 1CPU 	2874 	17 	17 	1000 	47.2% 	2894 	39.6%

40/40

Code: Select all

197 	Doch 09.980 x64 	2887 	16 	16 	1064 	53.9% 	2859 	39.8%

Doch is even more amazing at this infact. So your previous argument doesn't hold a candle, if this version doesn't have SE.

BTW, I checked that the both lists are calculated from the same database.