OliThink 5

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Re: OliThink 5

Postby Reinhard Scharnagl » 06 Nov 2004, 02:16

Hi Sune,
...from lazy evaluation, I think 20%-30%...

lazy positional evaluation seems to be even more efficient in Smirf, though caching is not yet helpful within the small testing trees:
Code: Select all
FEN: 3q2R1/2P5/1k1B4/4np2/1NPK1Pr1/1R6/PP1N1Q2/3q2b1 w - - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   [q]   :::<R>:::| (Compilation: Nov  6 2004)
7 |:::   <P>   :::   :::   | Testscenario QSearch(-max, +max):
6 |   [k]   <B>   :::   :::| TT Accesses 235872, Success 1.1%
5 |:::   :::   [n][p]:::   |
4 |   <N><P><K>   <P>[r]:::| Smirf Test No.: 00 (not lazy)
3 |:::<R>:::   :::   :::   |
2 |<P><P>   <N>   <Q>   :::| Evaluated Trees Count:  37*728
1 |:::   :::[q]:::   [b]   | TT Accesses per Second: 90965
=>+-a--b--c--d--e--f--g--h-+ Time:                   2.593 sec

  99.99 c7xd8Q+  16.78 c7xd8B+  11.96 Kd4xe5+  10.96 Rg8xd8   9.867 c7xd8R
  9.285 Nb4-c6+  9.266 Nb4-d5+  9.148 Nb4-c2+  9.082 Nb4-d3+  9.027 Nb4-a6+
  8.973 c4-c5+   8.898 Kd4-c3+  8.871 Kd4-d5+  7.977 c7xd8N   7.215 c7-c8N+
  5.910 Rg8xg4   4.852 c7-c8Q   4.465 Qf2xg1   4.020 Rb3-e3   1.473 c7-c8R
  1.074 Rb3-a3   0.980 Rb3-c3   0.953 Rb3-h3   0.934 Rb3-g3   0.902 Rg8-h8
  0.895 a2-a3    0.871 Rb3-d3   0.867 Qf2-e3   0.855 a2-a4    0.832 Rg8-f8
  0.809 Rg8-e8   0.809 Rg8-g6   0.801 Rg8-g5   0.797 Rb3-f3   0.773 Rg8-g7
 -0.230 c7-c8B  -99.99 Kd4-e3

FEN: 3q2R1/2P5/1k1B4/4np2/1NPK1Pr1/1R6/PP1N1Q2/3q2b1 w - - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   [q]   :::<R>:::| (Compilation: Nov  5 2004)
7 |:::   <P>   :::   :::   | Testscenario QSearch(-max, +max):
6 |   [k]   <B>   :::   :::| TT Accesses 223496, Success 0.6%
5 |:::   :::   [n][p]:::   |
4 |   <N><P><K>   <P>[r]:::| Smirf Test No.: 00 (lazy)
3 |:::<R>:::   :::   :::   |
2 |<P><P>   <N>   <Q>   :::| Evaluated Trees Count:  37*728
1 |:::   :::[q]:::   [b]   | TT Accesses per Second: 166415
=>+-a--b--c--d--e--f--g--h-+ Time:                   1.343 sec

  99.99 c7xd8Q+  16.78 c7xd8B+  11.96 Kd4xe5+  10.96 Rg8xd8   9.867 c7xd8R
  9.285 Nb4-c6+  9.266 Nb4-d5+  9.148 Nb4-c2+  9.082 Nb4-d3+  9.027 Nb4-a6+
  8.973 c4-c5+   8.898 Kd4-c3+  8.871 Kd4-d5+  7.977 c7xd8N   7.215 c7-c8N+
  5.910 Rg8xg4   4.852 c7-c8Q   4.465 Qf2xg1   4.020 Rb3-e3   1.473 c7-c8R
  1.074 Rb3-a3   0.980 Rb3-c3   0.953 Rb3-h3   0.934 Rb3-g3   0.902 Rg8-h8
  0.895 a2-a3    0.871 Rb3-d3   0.867 Qf2-e3   0.855 a2-a4    0.832 Rg8-f8
  0.809 Rg8-e8   0.809 Rg8-g6   0.801 Rg8-g5   0.797 Rb3-f3   0.773 Rg8-g7
 -0.230 c7-c8B  -99.99 Kd4-e3

Regards, Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: OliThink 5

Postby Uri Blass » 06 Nov 2004, 02:53

Sune Fischer wrote:Hi Reinhard and Uri,

Reinhard, the number just indicates the speed increase it gets by using a pawn hash.

There are otherways to speed things up, i.e. lazy eval and such, but these are imperfect improvements because you get sligtly less accurate eval and probably different node counts.

However, there is also a good speed up from lazy evaluation, I think 20%-30% faster due to the lazy eval stuff.

Uri, a pawn hash can be used for anything involving pawns, or pawns+kings or whatever you xor into the key.
Trapped bishops involves also bishops but most of the computation is about analyzing the pawn structure so this can be hashed and reused cheaply.

If I were you I would test and see if a hash gives a speedup, rather than assume it doesn't.

Once you start playing with this stuff you realize that you can do almost anything for free as long as it gets pawn hashed!
Quite a gift really if you think about it, worth getting the creative juices flowing over this one, IMO.

-S.


I assume it does not because I found in the past no big speed difference.
I do not detect trapped bishops

I thought that hash may help me to detect information about passed pawns and isolated pawns faster but it does not.

Note that this information is updated incrementally after every node because I evaluate every node.

I also remember that Gerd said that storing information in the hash is not good for passed pawns and isolated pawns and defended passed pawns and I have not something more complicated that is dependent only on pawns.

I evaluate blocked passed pawns as less important but this cannot be hashed because this is dependent on pieces that are not pawns.

I remember that I tried to give bonus for 2 passed pawns side by side but for some reason it seemed not to be productive for me so it is not evaluated and the same is for backward pawns.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: OliThink 5

Postby Sune Fischer » 06 Nov 2004, 03:09

Hi Reinhard,

I have relative big margins for lazy eval, probably too high.
It's a tuning process as with anything else, but I thought it best to put them so high that they never triggered falsely.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: OliThink 5

Postby Sune Fischer » 06 Nov 2004, 03:25

Hi Uri,

I get the impression that you just don't have that much pawn code. You might not get a big difference if you have never coded with a pawn hash in mind, the more you put in there the bigger the savings you get.

The things you tried didn't work you say, but why didn't they work?
Were they too expensive or could you not find the right terms and weights to use?
If it was because it was too slow then maybe the pawn hash is what you need for it to be productive.

I know Gerd and some others don't "believe" in a pawn hash, but I think they simply don't know how to use it correctly then. You can store a lot of compressed information solely about the pawns and then just assign the scores outside where you have complete position knowledge.

Also keep in mind that Gerd writes 64 bit assembler for breakfast, he does things in a way you and I can only dream of :)

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: OliThink 5

Postby Uri Blass » 06 Nov 2004, 04:00

Hi Sune,

I decided that it is better for me not to care too much about speed and I decided that I will allow the user to change a lot of parameters in the program.

The possibility of the user to change parameters cost speed but I believe that the possible improvement that users may give me by changing search and evaluation parameters is higher.

I do not think that things that I tried did not work because of speed.
The difference in speed from adding more pawn knowledge that did not work was very small(as far as I remember it was less than 10% speed reduction and I expect important knowledge to help even if the program is 10% slower).

I also do not think that I tried too high parameters(I uually start with parameters that I believe to be too low).
It is possible that other parameters were not adapted.

For example you may have too low value for passed pawn but if you increase value of passed pawns you may get negative effect of bad trade and it means that you need to increase the value of knights and bishops in order to increase the value of passed pawn in a productive way.

It is also possible that things that I tried did not work because of some bug in my code so I may try again to add knowledge about pawn structure but I do not need pawn hash in order to add knowledge in a cheap way.

Another possibility is that I did not play enough games and gave up too early.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: OliThink 5

Postby Reinhard Scharnagl » 06 Nov 2004, 04:03

Hi Sune,
... but I thought it best to put them so high that they never triggered falsely.

if you insist on NEVER then you better do not try it. But I have noticed only slight differences in less than 0.1% of move evaluations, and only in situations with a huge advantage of one side. Thus I am convinced it might not have bad consequences.

Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: OliThink 5

Postby Sune Fischer » 06 Nov 2004, 12:40

Hi Uri,

I decided that it is better for me not to care too much about speed and I decided that I will allow the user to change a lot of parameters in the program.

The possibility of the user to change parameters cost speed but I believe that the possible improvement that users may give me by changing search and evaluation parameters is higher.


A lot of engines have these configurations, mine included and I've never received suggestions for better settings.
Maybe you will have more luck, I guess Movei is better branded.

I do not think that things that I tried did not work because of speed.
The difference in speed from adding more pawn knowledge that did not work was very small(as far as I remember it was less than 10% speed reduction and I expect important knowledge to help even if the program is 10% slower).


If it works 5% but slows you down 10% it will (appear) not to work.
With a pawn hash it will only slow you down 0.1% so you have a better chance to see it working.

I do not need pawn hash in order to add knowledge in a cheap way.


I don't quite believe that.
If you have implemented the pawn eval in an incremental way it isn't easy to see how much it costs.

Another possibility is that I did not play enough games and gave up too early.


I'm not sure playing games is the best first test for the evaluation.
For instance pawn race eval will not be used in every game, it's better to design some test positions and see that it works. Perhaps setup some endgame positions and let it play them out and see if it scores relatively better.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: OliThink 5

Postby Uri Blass » 06 Nov 2004, 14:43

Hi sune,

some notes:
1)I have some original parameters that there are not in other programs
because they are based on original ideas.

I only found in the past that using them is probably better than not using them but I had no time to investigate their optimal value.

Testers of movei can play not only with the piece square table but with original parameters.

I know that I still did not implement some standard stuff so I am optimistic of future improvement.

For example as I reported earlier movei has no special function to generate only captures and it looks at all legal moves to look for captures.
I suspect that movei is the only program that has that problem and is not more than 400 elo weaker than shredder.

I need to change it but it also mean changing my mobility evaluation so it is not only adding function to generate only captures.

The latest version that I sent to testers has not all the possible
parameters that can be changed and I did not let the user to change null move pruning or mate extensions.


2)The evaluation of pawn structure is not incremental but
the bitboards that gives information about passed pawns and isolated pawns are updated incrementally.

3)I agree that the first test of positional evaluation should be to see if it get the expected result in some positions(I use also to look at the evaluation after search and compare with previous version).

Unfortunately I cannot test every position so I cannot be sure of no bugs.
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Previous

Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 18 guests