Move encoding

[Tom Likens]

For Maverick I have a move directory for all possible moves. So my move encoding is a simple pointer.

Steve

Does this mean that on 64-bit machines each move is 8-bytes long, (the size of a pointer)? If yes, this seems really inefficient.

[Steve Maughan]

Hi Tom,

I'm not sure but I presume so. The benefit is what you can store in the move dictionary, not the size of the pointer.

Nevertheless Maverick is quite fast as chewing through nodes.

Steve

[Tom Likens]

Hi Tom,

I'm not sure but I presume so. The benefit is what you can store in the move dictionary, not the size of the pointer.

Nevertheless Maverick is quite fast as chewing through nodes.

Steve

Hey Steve,

Do you store the 8-bytes in the hash table as well? BTW, I've no doubt of Maverick's speed but what program can't benefit from being faster?

regards,
--tom

[Steve Maughan]

Hi Tom,

Yes, I store a pointer to the hash move in the hash table.

Steve

[rreagan]

I like very much the opposite: to have a move with all the information. It allows me to have move-processing functions that would not depend on the board or anything else. That allows a better encapsulation, and better sanity checks if the idea is to avoid bugs. It is also more flexible because it is less dependent, and improves chances of modularity. I do not think there is one "truth" in this.

All the decoding is done through macros (from = MV_FROM(move); etc.)

Miguel

But a move without a board has no meaning. You could do the same amount of sanity checking, and more, if you have a move and a board.

I am not overly concerned with some holy grails of encapsulation and modularity for the sake of those things. A chess engine does not benefit greatly from superbly reusable code. It benefits from code that is correct.

I think the SPOT concept is closer to correct if it is practical. You could have a 64-byte array and compute all bitboards on the fly, and that would be most correct, but not efficient enough. So you need both, as part of automated testing (assert and friends), with the ability to change the implementation.

The same question could be asked about attacks. Do you generate them all up front, guaranteed to generate them only once? Or do you generate them on the fly, risking that you might generate the same attack board multiple times per position? I think the answer is, you wrap it up so you can do both, with extensive automated testing built in under the hood.

So you hide some implementation details, but having a move that is completely decoupled from the board doesn't seem that beneficial.

[rreagan]

Hi Tom,

Yes, I store a pointer to the hash move in the hash table.

Steve

What if you stored an index value into the lookup table instead of a 64-bit pointer? If the lookup table is 64x64, or if you had a deterministic move generator you could use a single byte (never more than 256 legal moves), and either way you save a good amount of space.

[Steve Maughan]

Hi Russell,

That seems like a good idea. I'll give it a try.

Thx

Steve

[michiguel]

I like very much the opposite: to have a move with all the information. It allows me to have move-processing functions that would not depend on the board or anything else. That allows a better encapsulation, and better sanity checks if the idea is to avoid bugs. It is also more flexible because it is less dependent, and improves chances of modularity. I do not think there is one "truth" in this.

All the decoding is done through macros (from = MV_FROM(move); etc.)

Miguel

But a move without a board has no meaning. You could do the same amount of sanity checking, and more, if you have a move and a board.

I am not overly concerned with some holy grails of encapsulation and modularity for the sake of those things. A chess engine does not benefit greatly from superbly reusable code. It benefits from code that is correct.

The code is correct. That is not an option.

I think the SPOT concept is closer to correct if it is practical. You could have a 64-byte array and compute all bitboards on the fly, and that would be most correct, but not efficient enough. So you need both, as part of automated testing (assert and friends), with the ability to change the implementation.

The same question could be asked about attacks. Do you generate them all up front, guaranteed to generate them only once? Or do you generate them on the fly, risking that you might generate the same attack board multiple times per position? I think the answer is, you wrap it up so you can do both, with extensive automated testing built in under the hood.

So you hide some implementation details, but having a move that is completely decoupled from the board doesn't seem that beneficial.

It was beneficial to me. I wrote a bunch of functions 15 years ago and I did not touch them anymore. For instance, I do not need to pass a board (its structure has changed) to print a humanly readable move (unless it is SAN of course). Many debugging functions can print exactly what move it is, print the whole PV etc. In sorting moves, I can tell what they are etc. In unmaking moves, since the piece taken is included, I do not need anything else etc.

To me, it helped me to have fewer bugs, not more, because assertions are more powerful. It really depends on the context and either solution is not better than another, and that was the point I tried to make.

Miguel

[rreagan]

What language is Gaviota written in?

[michiguel]

What language is Gaviota written in?

C

Miguel