Thinker output

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

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
CThinker
Posts: 388
Joined: Wed Mar 08, 2006 9:08 pm
Contact:

Re: Thinker output

Post by CThinker » Mon Mar 23, 2009 9:59 pm

Graham Banks wrote:
CThinker wrote: And, I don't work on the Thinker code anymore.
Are you working on a new engine?
No, not really. Kerwin does all the Thinker development now. He does a much better, elegant and cleaner job anyway.

I'm "trying" to port the current code to the DS platform. That is progressing slow.

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Thinker output

Post by bob » Mon Mar 23, 2009 10:26 pm

CThinker wrote:
hgm wrote:
CThinker wrote:And btw, Harm, I'm surprised that you used the 'easy' command as an example:

Code: Select all

C:\Temp\umax>umax.exe
tellics say         micro-Max 1.6w
tellics say         by H.G. Muller
easy
Error (unknown command): easy
hard
Error (unknown command): hard
quit

C:\Temp\umax>
Well, that I am a lazy SOB does not imply others should be forgiven for acting the same way! :lol: :lol: :lol: Micro-Max cannot ponder at all, and I guess replying "unkown command" to "hard" is a good way to let the GUI know about it. (Not that any existing GUI does anything with that info...). But I agree that it is not logical to give the same to "easy". Note that uMax 1.6w has not been worked on from the time I first released it as a WB engine, which was at a time when I did not work on WB at all, and hardly knew the protocol. My current policy is to let my engines recognize all WB commands that are sent by default, even if only for the purpose to ignore them (like "computer", "ratings", "otim" etc.).

You have point about existing protocols being tailored for a specific implemetation of a chess engine (tree search with iterative deepening). But I am pretty sure Thinker does get its moves that way. So this in itself is no excuse for violating the protocol. In the end you get a PV somehow, don't you? It would already be a great improvement if you print that PV before printing the move (so it is not discarded as ponder output, and ends up in the PGN file).

For me looking at the depth/score and PV info is all the fun. Without it, computer Chess is quite meaningless. This was rubbed in again recently, when I converted some XQ engines from another protocol to WB, through an adapter. That other protocol does not give thinking output, so there is nothing I could do about that. But it is just no fun seeing thoe engines play, knowing not even if they thinnk they are winning or losing.
hgm wrote:
CThinker wrote:And btw, Harm, I'm surprised that you used the 'easy' command as an example:

Code: Select all

C:\Temp\umax>umax.exe
tellics say         micro-Max 1.6w
tellics say         by H.G. Muller
easy
Error (unknown command): easy
hard
Error (unknown command): hard
quit

C:\Temp\umax>
Well, that I am a lazy SOB does not imply others should be forgiven for acting the same way! :lol: :lol: :lol: Micro-Max cannot ponder at all, and I guess replying "unkown command" to "hard" is a good way to let the GUI know about it. (Not that any existing GUI does anything with that info...). But I agree that it is not logical to give the same to "easy". Note that uMax 1.6w has not been worked on from the time I first released it as a WB engine, which was at a time when I did not work on WB at all, and hardly knew the protocol. My current policy is to let my engines recognize all WB commands that are sent by default, even if only for the purpose to ignore them (like "computer", "ratings", "otim" etc.).

You have point about existing protocols being tailored for a specific implemetation of a chess engine (tree search with iterative deepening). But I am pretty sure Thinker does get its moves that way. So this in itself is no excuse for violating the protocol. In the end you get a PV somehow, don't you? It would already be a great improvement if you print that PV before printing the move (so it is not discarded as ponder output, and ends up in the PGN file).

For me looking at the depth/score and PV info is all the fun. Without it, computer Chess is quite meaningless. This was rubbed in again recently, when I converted some XQ engines from another protocol to WB, through an adapter. That other protocol does not give thinking output, so there is nothing I could do about that. But it is just no fun seeing thoe engines play, knowing not even if they thinnk they are winning or losing.
I think you have made a clear example there Harm - your engine does not ponder. That means it cannot support a set of xboard commands.

Micromax also does not support the 'move now' ("?") command. I use micromax to play, and I would rather have the 'move now' command than the PV display. It is very common for me to get bored, and I just need the engine to make the move.

But I understand all these, because I have the same set of limitations with Thinker.

As for PV, Thinker does not have one. It does not collect PV arrays. Again, just like MicroMax. Thinker is actually patterned after the Amy engine. The PV display that you get from Thinker is nothing more than a walk of the hash table (just like... Amy).

The ways that other engines collect PV arrays look very hacky to me. They either allocate a square array, but use only half of it, or, allocates PV arrays on the stack on each call to a search function. Neither is acceptable to me. So, until I device a really clean solution, I am not inclined on polluting the Thinker code.

The current code is really clean, very compartmentalized, and only contains the necessary code to find a good-enough root move and relay that to the user.

I could chose to make a giant monolithic engine (just like the others out there) and support the fancy protocol items, or, I can chose to make a small, cleanly structured engine that I can easily understand. I chose the latter. But that's just me.

Remember, when Thinker fist came out, the book engine (BookThinker) is separate from the search engine. BookThinker was actually the first of its kind at that time. Later, there was a huge struggle on whether the book code should go with the search code, because really, they do two very disjoint operations (file operations vs in-memory tree search). Many programmers here probably don't struggle with such design and architecture decisions, but I do.

We eventually found a clean way of having both to co-exist in the same architecture ("strategy" pattern, from 'design patterns'). I value that elegance of design and implementation. But again, that's just me.
My only question is this: Why would you not collect the PV on the fly by backing it up along with the score? A PV harvested from the trans/ref table is inaccurate, and (IMHO) makes it harder to debug things. I often look at a PV and score from Crafty, then run down the PV and repeatedly use the score command to tweak things to bring the score closer to what seems reasonable. A hash PV is almost guaranteed to not lead you to the actual position that was scored, which makes debugging much more complicated...

And backing up the PV is not expensive.

User avatar
Dr.Wael Deeb
Posts: 9773
Joined: Wed Mar 08, 2006 7:44 pm
Location: Amman,Jordan

Re: Thinker output

Post by Dr.Wael Deeb » Mon Mar 23, 2009 11:10 pm

fern wrote:Dear Lance, design your engine as you wish.
I am one of those weird guys that use engines to PLAY, yes, to PLAY, so I can live without the PV line and in fact it is an advantage to me not to be tempted to see how is that the engine will kill me.
Of course most of the pals here use the engines for analysis or whatever, so they feel outraged.
My only demand is this: keep working in Thinker Or create an even better engine.
that is what a sound and sane amateur should ask, I believe.

Fern
That's makes two of us :D
Dr.D
_No one can hit as hard as life.But it ain’t about how hard you can hit.It’s about how hard you can get hit and keep moving forward.How much you can take and keep moving forward….

swami
Posts: 6546
Joined: Thu Mar 09, 2006 3:21 am

Re: Thinker output

Post by swami » Mon Mar 23, 2009 11:35 pm

Dr.Wael Deeb wrote:
fern wrote:Dear Lance, design your engine as you wish.
I am one of those weird guys that use engines to PLAY, yes, to PLAY, so I can live without the PV line and in fact it is an advantage to me
Fern
That's makes two of us :D
Dr.D
Count me in, but then again sometimes I get to play only once a week not as frequently as I used to.

User avatar
Dr.Wael Deeb
Posts: 9773
Joined: Wed Mar 08, 2006 7:44 pm
Location: Amman,Jordan

Re: Thinker output

Post by Dr.Wael Deeb » Mon Mar 23, 2009 11:53 pm

swami wrote:
Dr.Wael Deeb wrote:
fern wrote:Dear Lance, design your engine as you wish.
I am one of those weird guys that use engines to PLAY, yes, to PLAY, so I can live without the PV line and in fact it is an advantage to me
Fern
That's makes two of us :D
Dr.D
Count me in, but then again sometimes I get to play only once a week not as frequently as I used to.
Yeah Swami,sometimes I wish I could live in a big library with a chess board,my chess engines and play and play.... :D
Here is my latest game against a chess engine in one of my running tournaments:

[Event "DCCW_RL 2008"]
[Site "Jordan"]
[Date "2009.03.15"]
[White "Dr.Wael Deeb_2032"]
[Black " pikoSzachy 3.1 wb_2228"]
[Result "1-0"]
[ECO "B42"]
[Opening "Sicilian Defence"]

1.e4 c5 2.Nf3 e6 3.d4 cxd4 4.Nxd4 a6 5.Bd3 Bc5 6.Nb3 Be7 7.0–0 d6 8.c4 Nf6 9.Nc3 Nbd7 10.f4 a5 11.Nd4 0–0 12.Be3 Nc5 13.Bc2 Qb6 14.Rb1 h5 15.h3 g6 16.f5 Bd7 17.fxg6 fxg6 18.Nb3 Be8 19.Nxc5 dxc5 20.Qe1 Nd7 21.Rxf8+ Nxf8 22.Qg3 h4 23.Qg4 Nd7 24.Bf4 Bf6 25.e5 Nxe5 26.Bxe5 Bxe5 27.Bxg6 Bd4+ 28.Kh1 Bg7 29.Bc2 Rd8 30.Qxh4 Rd7 31.Qh7+ Kf8 32.Ba4 Re7 33.Bxe8 Kxe8 34.Qg6+ Kd8 35.Rd1+ Bd4 36.Nb5 Kc8 37.Qg8+ Kd7 38.Qg4 Kc8 39.Nxd4 cxd4 40.Qxd4 Qxd4 41.Rxd4 e5 42.Rd1 Kc7 1-0

When the engine played his 14th move,I sensed the absence of any sign of King's safety and went for winning....
Dr.D
Last edited by Dr.Wael Deeb on Mon Mar 23, 2009 11:56 pm, edited 1 time in total.
_No one can hit as hard as life.But it ain’t about how hard you can hit.It’s about how hard you can get hit and keep moving forward.How much you can take and keep moving forward….

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Thinker output

Post by bob » Mon Mar 23, 2009 11:56 pm

CThinker wrote:
Graham Banks wrote:
CThinker wrote: And, I don't work on the Thinker code anymore.
Are you working on a new engine?
No, not really. Kerwin does all the Thinker development now. He does a much better, elegant and cleaner job anyway.

I'm "trying" to port the current code to the DS platform. That is progressing slow.
Did that for Crafty. Assuming DS = nintendo DS. Slow processor, odd memory setup, not to mention small memory, etc. :)

glorfindel

Re: Thinker output

Post by glorfindel » Tue Mar 24, 2009 12:03 am

So how fast does crafty run on a DS? Do you have an estimation of playing strength perhaps?

CThinker
Posts: 388
Joined: Wed Mar 08, 2006 9:08 pm
Contact:

Re: Thinker output

Post by CThinker » Tue Mar 24, 2009 12:31 am

bob wrote: My only question is this: Why would you not collect the PV on the fly by backing it up along with the score? A PV harvested from the trans/ref table is inaccurate, and (IMHO) makes it harder to debug things. I often look at a PV and score from Crafty, then run down the PV and repeatedly use the score command to tweak things to bring the score closer to what seems reasonable. A hash PV is almost guaranteed to not lead you to the actual position that was scored, which makes debugging much more complicated...

And backing up the PV is not expensive.
It is all about simplicity. It may not be expensive as far as run-time is concerned, but it is still extra ugly code. To me, at least, it looks like that.

Even within Thinker, the implementation of search is hidden from the shell. The tree search is just one form of search. The book search is another. Both have completely different behavior. So, the shell does not care how they find the best move. The shell just knows that they will return one.

To the shell, the book search and the tree search are just "strategies" (in design pattern speak). So, even if I implement a PV collection in the tree search, would I want to expose that? That means the book search would have to return a PV also? That means that any "search strategy" always include a PV. I could design it that way, but that would be a very bad design. That may not be a big deal to others, but it is to me.

Just to give an idea of the simplicity that I am talking about, below is a comparison of the call graphs of Fruit 2.3.1, Crafty 22.9 and Thinker 5.4C.

Cheers...

Image

Image

Image

http://www.winboardengines.de/thinker/C ... -2-3-1.bmp
http://www.winboardengines.de/thinker/C ... y-22-9.bmp
http://www.winboardengines.de/thinker/C ... ker54C.bmp

CThinker
Posts: 388
Joined: Wed Mar 08, 2006 9:08 pm
Contact:

Re: Thinker output

Post by CThinker » Tue Mar 24, 2009 12:34 am

bob wrote:
CThinker wrote:
Graham Banks wrote:
CThinker wrote: And, I don't work on the Thinker code anymore.
Are you working on a new engine?
No, not really. Kerwin does all the Thinker development now. He does a much better, elegant and cleaner job anyway.

I'm "trying" to port the current code to the DS platform. That is progressing slow.
Did that for Crafty. Assuming DS = nintendo DS. Slow processor, odd memory setup, not to mention small memory, etc. :)
Yup. The Nintendo DS. With all those limitations that you mentioned, I think the Thinker code will feel so at home on it.

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Thinker output

Post by bob » Tue Mar 24, 2009 5:37 am

glorfindel wrote:So how fast does crafty run on a DS? Do you have an estimation of playing strength perhaps?
It's been a while, I believe it was in the 30K nodes per second range. I was asked to do this for a game company a couple of years ago. I had to get rid of rotated bitboards due to space and did a direct calculation to generate moves, which is about 10% slower than rotated/magic. I also had to remove lots of "extras" and use a _really_ small hash table.

I don't remember the specifics however as this was just a quick-and-dirty port...

Post Reply