Author: Gian-Carlo Pascutto
Date: 16:06:26 01/02/00
Go up one level in this thread
On January 02, 2000 at 17:43:50, John Hendrikx wrote:
>
> 220 ms d2-d3 [24] moves = 20 (0 = transposed)
> 440 ms d2-d3 d7-d6 [0] moves = 69 (0)
> 1100 ms d2-d3 d7-d6 b1-c3 [22] moves = 523 (0)
> 2640 ms d2-d3 d7-d6 b1-c3 b8-c6 [0] moves = 1555 (93)
> 4840 ms d2-d3 b8-c6 b1-c3 d7-d6 g1-f3 [22] moves = 24820 (286)
> 11150 ms e2-e3 e7-e6 d2-d3 g8-e7 g1-f3 b8-c6 [3] moves = 82580 (3250)
> 75580 ms e2-e3 g8-f6 f1-c4 d7-d5 c4-d3 h7-h6 g1-f3 [16] moves = 933153 (7686)
>
>Slower, and different scores...
None of those specifically indicates you have anything broken.
I believe ETC didn't work for most people that tried it. (i.e.
no improvement)
>null-moves were disabled in both cases.
>The results I get here lead me to believe I've implemented the Transposition
>Table incorrectly or something. I really don't see the harm in testing all
>moves in the TT for a cutoff at once, instead of doing them one by one during
>the search.
The catch with ETC is that a full movegen+checking each move is usually
slower than trying the first and getting a cutoff right away (something
that should happen in 85+% of the cases)
[snip]
> if(result >= beta) { // Any more I could do with the result?
> return result;
> }
> }
If the result from your nullmove search is -INF (mated), you'll usually
want to extend the position.
> while(i.hasNext()) { // Loop through all moves.
> Move move=(Move)i.next();
> int e;
> int newHash=(hash ^ piecePositionHash[((board.whitesTurn ? 0 : 1)<<10)
> + ((Math.abs(board.pieceAt(move.source))-1)<<6)
> + move.source]) ^ piecePositionHash[((board.whitesTurn ? 0 : 1)<<10)
> + ((Math.abs(board.pieceAt(move.source))-1)<<6) + move.destination];
Hmm...doesn't this break on en-passant, castle...etc moves ?
--
GCP
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.