Unifying make/undo and copy-make

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Fabio Gobbato
Posts: 168
Joined: Fri Apr 11, 2014 8:45 am
Full name: Fabio Gobbato

Re: Unifying make/undo and copy-make

Post by Fabio Gobbato » Tue Dec 22, 2015 7:43 pm

My engine is not very strong but I use copy/make too. My board structure stay in 56 bytes, the copy is very fast.

Aleks Peshkov
Posts: 886
Joined: Sun Nov 19, 2006 8:16 pm
Location: Russia

Re: Unifying make/undo and copy-make

Post by Aleks Peshkov » Tue Dec 22, 2015 8:26 pm

My attack table size is 256 bytes, but it would be obviously very slow to unmake the incremental changes. So I copy the whole ~400 bytes position.

My program still at perft stage but it is not slow with my attack tables. It is comparable to the fastest known performers.

User avatar
Posts: 3184
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart

Re: Unifying make/undo and copy-make

Post by lucasart » Tue Dec 22, 2015 11:20 pm

Rein Halbersma wrote:
Bloodbane wrote:
jdart wrote:I don't know of any strong program that uses copy-make.

The only engine I know that uses copy-make and is even near the top engines is Hakkapeliitta. According to my notes copy-make was actually slightly faster than make-unmake.
As far as I have been able to find on this forum, all engines written by Don Dailey have been copy-make, all the way back from the days of CilkChess right up to Komodo.
I've done both, and I much prefer copy-make. Reason is that (if done correctly), the speed is about the same, and is a negligible part of your profiling result on a fully blown program anyway (where search and eval count much more). And copy-make is much more elegant. You can make your Position class "const" everywhere it should be "const". You needn't have an unmake function. And you avoid a whole bunch of possible bugs, simply, by not having an undo function. By definition, you cannot propagate bugs. You can really debug step by step, until you find the node where your movegen or make code went wrong. You cannot have path dependant bugs that a nightmarish to find.

Here's my latest copy-make. It was an attempt to rewrite DiscoCheck with SMP, but I got bored and gave up half way:
copy-make was really the correct design decision (among other things).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Post Reply