Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#ActualÁlvaro

Posted 22 April 2013 - 03:26 PM


I used to do that in my old engine (Ruy-López), but that requires you to generate all the moves before you even try the move from the transposition tables. Since this move very often produces a beta cutoff, it's worth writing a function that checks validity of a move on a given position and try to avoid generating the move list altogether.[/size]

I use a 16-bit format for the move, as described here: [/size]http://chessprogramming.wikispaces.com/Encoding+Moves

 
That's sound cheaper than what I implemented now, I'll try.
You said that you can encode a move in 16 bit, but as far as I know the minimum is 32 bit (how do you manage castle and en passants?).


Castling and en-passants are encoded in the 4-bit "move type" described in the page I linked to. That plus 6-bit "to" and "from" gets you to 16 bits.

Omitting this, I made some test when i was working on the move generator and it came out that my move encoding (which is a class with 4 byte fields ) is faster than using a single 32 bit integer for representing it. Should I change encode method for saving some memory in the transposition table?

No, you can always convert to and from the 16-bit format just for transposition-table access. That shouldn't be too slow.
 


That's a very difficult question. A few ideas:[/size]
* You can run a search up to depth D (I assume you are using iterative deepening) and then rerun it without clearing the transposition tables: It should be almost instantaneous.[/size]
* You can run a long search on a position with and without transposition tables, and the version with transposition tables should generally get to the same depth faster.[/size]
* You can match your program against itself, with and without transposition tables, at a fixed depth, and the results should be even.[/size]

 
for trying  point one I should first implement iterative deeping (when should i do that?).


Now would be a good time. It's basically impossible to implement time control without it, and it's very hard to work with an engine that doesn't control time properly.

P.S. I've just implemented MVV-LVA and the search is now MUCH faster! thank you.

Yup, that one is a biggie.

#1Álvaro

Posted 22 April 2013 - 08:03 AM


I used to do that in my old engine (Ruy-López), but that requires you to generate all the moves before you even try the move from the transposition tables. Since this move very often produces a beta cutoff, it's worth writing a function that checks validity of a move on a given position and try to avoid generating the move list altogether.[/size]

I use a 16-bit format for the move, as described here: [/size]http://chessprogramming.wikispaces.com/Encoding+Moves

 
That's sound cheaper than what I implemented now, I'll try.
You said that you can encode a move in 16 bit, but as far as I know the minimum is 32 bit (how do you manage castle and en passants?).


Castling and en-passants are encoded in the 4-bit "move type" described in the page I linked to. That plus 6-bit "to" and "from" gets you to 16 bits.

Omitting this, I made some test when i was working on the move generator and it came out that my move encoding (which is a class with 4 byte fields ) is faster than using a single 32 bit integer for representing it. Should I change encode method for saving some memory in the transposition table?

No, you can always convert to and from your encoding to the 16-bit format just for transposition-table access. That shouldn't be too slow.
 


That's a very difficult question. A few ideas:[/size]
* You can run a search up to depth D (I assume you are using iterative deepening) and then rerun it without clearing the transposition tables: It should be almost instantaneous.[/size]
* You can run a long search on a position with and without transposition tables, and the version with transposition tables should generally get to the same depth faster.[/size]
* You can match your program against itself, with and without transposition tables, at a fixed depth, and the results should be even.[/size]

 
for trying  point one I should first implement iterative deeping (when should i do that?).


Now would be a good time. It's basically impossible to implement time control without it, and it's very hard to work with an engine that doesn't control time properly.

P.S. I've just implemented MVV-LVA and the search is now MUCH faster! thank you.

Yup, that one is a biggie.

PARTNERS