Getting gray-matter to work within Scid

[GoogleCodeExporter]

Don't need scid at all to test this. Just launch gray-matter and paste
what Scid sends to us.
The FEN seems to be parsed ok.
What I don't understand yet is that after the 'go', no output is shown
(even though there was a 'post' before).

Here's what Scid sends us:

xboard
protover 2
ponder off
post
force
xboard
protover 2
ponder off
post

setboard rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
new
force
setboard rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
white

st 120000
sd 50
post
go

Original issue reported on code.google.com by jonne.z...@gmail.com on 23 Nov 2007 at 6:15

[GoogleCodeExporter]

Just figured out that, if I create a move m and say board_ptr->make(m) in
xboard::do_go(), it all works!
That seems to be the difference between Scid and xboard as well.
In xboard the analysis starts after a 'usermove m' command, which 
board_ptr->make(m)'s.

It's this bit of magic in board_ptr->make(m) that I'm probably looking for ;)

Original comment by jonne.z...@gmail.com on 23 Nov 2007 at 6:54

[GoogleCodeExporter]

This problem could be related to the problem I described in the source
in function search_mtdf::mtdf.

When the 'go' command is launched, instead of a 'usermove e2e4', I seem to
end up forever in this loop again:

  while (upper > lower && (!timeout_flag || !depth_flag))

while ANALYZING the timeout_flag will not be set.

Hmmmzzzz .... interesting ....

Original comment by jonne.z...@gmail.com on 23 Nov 2007 at 7:20

[GoogleCodeExporter]

Or ... is the real bug here that "upper > lower" remains true for so long?

Original comment by jonne.z...@gmail.com on 23 Nov 2007 at 7:24

[GoogleCodeExporter]

I suggest the following fix. But I don't know whether it's a good one.
Hope you have more to say about this.
(Q: if parameters are the same, will minimax return the same move with same 
value?)

Original comment by jonne.z...@gmail.com on 23 Nov 2007 at 9:10

Attachments:

• search.mtdf.cpp.patch

[GoogleCodeExporter]

Hey, Jonne.  :-)

I'll have a few free hours today, so I'll look through your patch then!  Thanks 
again for your great work!

Your friend,
Raj

Original comment by brainix on 24 Nov 2007 at 1:07

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It looks like Scid and XBoard implement The Chess Engine Communication Protocol 
slightly differently.  :-(

Original comment by brainix on 26 Nov 2007 at 3:34

[GoogleCodeExporter]

I guess so. But this is not so important I think.
The problem is that, while posting was set, I didn't see any lines of output.
This is because the 
  while (upper > lower && (!timeout_flag || !depth_flag))
loop in mtdf does not terminate.
You removed the depth_flag, that solved part of the problem. But what if 
there's no
alarm?
Obviously, at some point in time upper <= lower must hold. And exactly this is 
not
always the case. I think even in the initial situation this can go wrong. Maybe 
when
using the opening book, I don't know. Have to debug this a bit further. I had 
some
debugging lines showing this went wrong, but removed them. 
Maybe I can add a unit test later :)

Original comment by jonne.z...@gmail.com on 26 Nov 2007 at 2:24

[GoogleCodeExporter]

Here it is ...
The following simply happens when I fire up bin/gray
and enter:
 post
 go

[lower, upper] = [-32767, 32767], beta = 0
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
[lower, upper] = [-32767, -316], beta = 65220
m.value = -316
... infinite loop ...

Original comment by jonne.z...@gmail.com on 26 Nov 2007 at 2:29

• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Additional info:

First call to minimax(depth=1, 0, alpha=-1, beta=0) ::
  Returns in a recursive call to minimax for each of the twenty moves.
  These values range from -316 (Nc3 or Nf3 Kramnik!!, not e4 as many people believed)
to -343 (b3 or g3, what eco is that :)
  -316 is returned

All following calls to minimax(depth=1, 0, alpha=65219, beta=65220) ::
  table_ptr->probe(hash, depth, EXACT, &m) fails, contrary to what I expected
  table_ptr->probe(hash, depth, UPPER, &m) succeedes
  and m.value (-316) <= alpha (65219), so m is returned.

These two statements do nothing (because m.value < beta and upper == m.value):
  upper = m.value < beta ? m.value : upper;
  lower = m.value < beta ? lower : m.value;

So now, our infinite loop continues...

Original comment by jonne.z...@gmail.com on 26 Nov 2007 at 3:11

[GoogleCodeExporter]

Ok, so I noticed right after posting the previous message why it was stored in 
UPPER
table and not EXACT table. Because -316 was outside the [-1,0] window of course.

Ehm yeah, actually that beta value is weird isn't it? Don't know why I did not 
notice
that before, but it should be around m.value perhaps + 1....

That's why I added the following printf's:

    while (upper > lower && !timeout_flag)
    {
        printf("Old beta: %d, m.value: %d, %X.\n", beta, m.value, m.value);
        beta = m.value + (m.value == lower);
        printf("New beta: %d.\n", beta);
        m = minimax(depth, 0, beta - 1, beta);
        printf("minimax returns m with value %d, %X.\n", m.value, m.value);
        upper = m.value < beta ? m.value : upper;
        lower = m.value < beta ? lower : m.value;
        printf("minimax return, I repeat, m with value %d %X.\n", m.value, m.value);
        printf("New [lower, upper] = [%d, %d].\n", lower, upper);
    }
    return m;

And look what it outputs !

Old beta: 1, m.value: 0, 0.
New beta: 0.
minimax returns m with value -316, FFFFFEC4.
minimax return, I repeat, m with value -316 FFFFFEC4.
New [lower, upper] = [-32767, -316].
Old beta: 0, m.value: 65220, FEC4.
New beta: 65220.
minimax returns m with value -316, FFFFFEC4.
minimax return, I repeat, m with value -316 FFFFFEC4.
New [lower, upper] = [-32767, -316].
Old beta: 65220, m.value: 65220, FEC4.
New beta: 65220.

Does that have anything to do with the move struct?
m.value is not an int, but a signed: 16 ...
Hmmmz...

Original comment by jonne.z...@gmail.com on 27 Nov 2007 at 8:29

[GoogleCodeExporter]

Got it !!! (see commit) Don't I ???

Original comment by jonne.z...@gmail.com on 27 Nov 2007 at 8:42

[GoogleCodeExporter]

Problem when running in Scid now, is that Gray matter makes a move quickly 
(although
st and sd are set very large). And, hence, then ponders for the wrong player.
But this is more a bug in Scid, so I'm closing this issue.

Original comment by jonne.z...@gmail.com on 27 Nov 2007 at 9:23

• Changed state: Fixed

[GoogleCodeExporter]

I'm such a fool.  It's a good thing I have a genius on the team, debugging the 
code.  :-)  Yes, I think you got it.

I'm changing the status to Fixed.  I'll change it to Verified once I'm sure 
everything works perfectly.  Great job!

Original comment by brainix on 27 Nov 2007 at 9:23