This commit is contained in:
Miloslav Ciz 2023-10-03 20:43:52 +02:00
parent 7ca165bd2a
commit c532040215
4 changed files with 11 additions and 7 deletions

2
go.md
View file

@ -75,7 +75,7 @@ TODO
See also https://senseis.xmp.net/?ComputerGoProgramming and https://www.chessprogramming.org/Go.
**Board representation:** a straightforward representation of the go board is as a simple [array](array.md) of squares; each square can be either empty, white or black, that's 3 values that can be stored with 2 bits, which allow storing 4 values, leaving one extra value to be used for some other purpose (e.g. marking illegal ko squares, estimated dead stones, marking last move etc.). 1 byte allows us to store 4 squares this way so we need only 91 bytes to represent the whole 19x19 board. On computers with enough RAM it may be considered to store 1 square in a single byte, making the board take more space but gaining speed (we don't need extra instructions for squeezing bit from/to a byte). Of course we furthermore have to keep track of extra things such as numbers of captured stones.
**Board representation:** a straightforward representation of the go board is as a simple [array](array.md) of squares; each square can be either empty, white or black, that's 3 values that can be stored with 2 bits, which allow storing 4 values, leaving one extra value to be used for some other purpose (e.g. marking illegal ko squares, estimated dead stones, marking last move etc.). 1 byte allows us to store 4 squares this way so we need only 91 bytes to represent the whole 19x19 board. On computers with enough RAM it may be considered to store 1 square in a single byte or int, making the board take more space but gaining speed thanks to data alignment (we don't need extra instructions for squeezing bit from/to a single byte). Of course we furthermore have to keep track of extra things such as numbers of captured stones.
TODO