rexrangga / gray-matter

Automatically exported from code.google.com/p/gray-matter
0 stars 0 forks source link

Re8 revisited #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

hehe, I said there was something wrong with stalemate/checkmate ;)
It might have to do with my last commit.

 $ bin/gray
setboard 3R4/8/8/8/8/8/4p1K1/4k3 w - - 0 1
post
display
  +---+---+---+---+---+---+---+---+
  |   |   |   | R |   |   |   |   | 8
  +---+---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |   | 7
  +---+---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |   | 6
  +---+---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |   | 5
  +---+---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |   | 4
  +---+---+---+---+---+---+---+---+
  |   |   |   |   |   |   |   |   | 3
  +---+---+---+---+---+---+---+---+
  |   |   |   |   | p |   | K |   | 2
  +---+---+---+---+---+---+---+---+
  |   |   |   |   | k |   |   |   | 1
  +---+---+---+---+---+---+---+---+
    a   b   c   d   e   f   g   h
go
1 -310 1 21 Kf3
2 -270 1 65 Kf3 Kd2+
3 -10000 1 530 Kg1
move g2g1
1/2-1/2 {Stalemate}

Original issue reported on code.google.com by jonne.z...@gmail.com on 18 Dec 2007 at 8:49

GoogleCodeExporter commented 9 years ago
Also, I notice when swapping colors (w/b in FEN), black resigns in this 
position. But
black is not in check, so ... does the 'resign' result in a draw, or does GM
incorrectly resign here?

setboard 3R4/8/8/8/8/8/4p1K1/4k3 b - - 0 1
go
resign

Original comment by jonne.z...@gmail.com on 18 Dec 2007 at 8:51

GoogleCodeExporter commented 9 years ago
I see the problem. Below is debugging output for all possibilities starting 
with Kg1.
The final evaluation should be 0 - stalemate.
But her best alternative, the illegal move Kd2 putting herself in check,
evaluates to minus checkmate-value, because rook takes king on next move.

What way should we go... 
A) the get_status() proc becomes smarter and slower
B) the make(move) proc returns false for all illegal moves
   (i still think we benefit from generating pseudo-legal moves here, because
    due to pruning not all moves are searched recursively).
C) the minimax proc takes this into account. if, for a certain position, all
   moves lead to checkmate-values or illegal-values, something clever must be done.

I roughly guess that B could possibly be a not-so-bad idea.

 Kg1 Kd2+ Rxd2#: terminal state 5.
 Kg1 Kd2+ Kf1+: evaluate() says -230.
 Kg1 Kd2+ Kh1: evaluate() says -230.
 Kg1 Kd2+ Kh2: evaluate() says -250.
 Kg1 Kd2+ Ra8: evaluate() says -218.
 Kg1 Kd2+ Rb8: evaluate() says -222.
 Kg1 Kd2+ Rc8: evaluate() says -226.
 Kg1 Kd2+ Re8: evaluate() says -230.
 Kg1 Kd2+ Rf8: evaluate() says -226.
 Kg1 Kd2+ Rg8: evaluate() says -222.
 Kg1 Kd2+ Rh8: evaluate() says -218.
 Kg1 Kd2+ Rd7: evaluate() says -230.
 Kg1 Kd2+ Rd6: evaluate() says -230.
 Kg1 Kd2+ Rd5: evaluate() says -230.
 Kg1 Kd2+ Rd4: evaluate() says -230.
 Kg1 Kd2+ Rd3: evaluate() says -230.
 Kg1 Kd2+ (Rxd2#): max of childs 10000.
 Kg1 Kf1+: terminal state 6.
 Kg1 Kd1+ Rd2: evaluate() says -270.
 Kg1 Kd1+ Rxd1#: terminal state 5.
 Kg1 Kd1+ (Rxd1#): max of childs 10000.
 Kg1 Kf2+: terminal state 6.
 Kg1 (Kd2+): max of childs -10000.

Original comment by jonne.z...@gmail.com on 18 Dec 2007 at 9:17

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
This is still a problem:  Another example is: 

setboard 5K2/8/8/4qn2/8/8/8/4k3 b - - 0 1

In this example, gray should be able to find the
easy mate, but it can't. . I think because it
thinks Q to e7 results in a draw (before it
realizes that this is a win).  To fix it we'd
have to analyze every position more thoroughly,
but I don't think this is a good idea either
(it is very very slow).

Original comment by protonsp...@gmail.com on 24 Jul 2009 at 9:08

GoogleCodeExporter commented 9 years ago
@protonspring

I think the problem is, that after Qe7, gray matter wants to play the illegal 
move
Kxe7 (puts itself in check due to black's knight).

If i used this FEN string: setboard 5K2/4q3/8/5n2/8/8/8/4k3 w KQkq - 0 1
with arises after Qe7, I get the following debug output:

go
search_base::change changes state from IDLING to THINKING.
search_base::start doing requested work (hash = 6310d21dc4259cf1, status = 
THINKING).
: Setting alarm to 749 csecs from now.
: Iterative deepening maxdepth set to 1.
 Kxe7: terminal state 2.
 Kf7: Opponent's king can be captured - illegal position.
 Kg7: Opponent's king can be captured - illegal position.
 Ke8: Opponent's king can be captured - illegal position.
 Kg8 (Kd1): max of 35 children: 1236.
 (Kxe7): max of 5 children: 0.
: Iterative deepening maxdepth set to 2.
 Kxe7: terminal state 2.
 Kf7: Opponent's king can be captured - illegal position.
 Kg7: Opponent's king can be captured - illegal position.
 Ke8: Opponent's king can be captured - illegal position.
 Kg8 (Kd1): max of 35 children: 1236.
 (Kxe7): max of 5 children: 0.
: Iterative deepening maxdepth set to 3.
 Kxe7: terminal state 2.
 Kf7: Opponent's king can be captured - illegal position.
 Kg7: Opponent's king can be captured - illegal position.
 Ke8: Opponent's king can be captured - illegal position.
 Kg8 (Kd1): max of 35 children: 1236.
 (Kxe7): max of 5 children: 0.

And finally, it prints:

move f8e7
1/2-1/2 {Insufficient material}
search_base::change changes state from THINKING to IDLING.
search_base::start doing requested work (hash = 6310d21dc4259cf1, status = 
IDLING).

So yes, it wants to play the illegal move Kxe7 here...

Original comment by jonne.z...@gmail.com on 24 Dec 2009 at 10:35

GoogleCodeExporter commented 9 years ago
Think I found it.
state is INSUFFICIENT after Kxe7. There is not enough material so the game is 
drawn.
This is determined before figuring out the move Kxe7 is an illegal move...

Original comment by jonne.z...@gmail.com on 2 Jan 2010 at 10:03

GoogleCodeExporter commented 9 years ago
Confirmed.  When I disable insufficient material checking, gray matter finds 
the mate very fast.

Original comment by protonsp...@gmail.com on 26 Jul 2010 at 6:13

GoogleCodeExporter commented 9 years ago
I will close this WR and open another one which better describes this problem.

Original comment by protonsp...@gmail.com on 26 Jul 2010 at 6:30

GoogleCodeExporter commented 9 years ago
This issue moved to defect 44.

Original comment by protonsp...@gmail.com on 26 Jul 2010 at 6:30

GoogleCodeExporter commented 9 years ago
I don't seem to be able to close issues.

Is there some power someone could grant?

Original comment by protonsp...@gmail.com on 26 Jul 2010 at 8:39

GoogleCodeExporter commented 9 years ago
Hello.

I glanced through the permissions, and I couldn't figure out how to grant 
project contributors the power to close issues.  I'll close this one for you, 
and I'll take a deeper look tonight.

If I can't figure it out, I'll make you a project owner.

Thanks,
Raj

Original comment by brainix on 26 Jul 2010 at 8:45

GoogleCodeExporter commented 9 years ago
Come to think of it - you should be able to close issues.  When you start 
typing, you should get some options underneath.  And you should be able to set 
the status to "Fixed".

I'll confirm this myself with another Google account.

Thanks,
Raj

Original comment by brainix on 26 Jul 2010 at 8:46