I would think it would be possible to cut the space of possible chess positions down quite a bit by only retaining those which can result from moves the AI would make, and legal moves an opponent could make in response. That is, when it becomes clear that a position is unwinnable, backtrack, and don’t keep full notes on why it’s unwinnable.
This is more or less what computers do today to win chess matches, but the space of possibilities explodes too fast; even the strongest computers can’t really keep track of more than I think 13 or 14 moves ahead, even given a long time to think.
Merely storing all the positions that are unwinnable—regardless of why they are so—would require more matter than we have in the solar system. Not to mention the efficiency of running a DB search on that...
Not to mention the efficiency of running a DB search on that...
Actually, with proper design, that can be made very quick and easy. You don’t need to store the positions; you just need to store the states (win:black, win:white, draw—two bits per state).
The trick is, you store each win/loss state in a memory address equal to the 34-byte (or however long) binary number that describes the position in question. Checking a given state is then simply a memory retrieval from a known address.
I suspect that with memory on the order of 10^70 bytes, that might involve additional complications; but you’re correct, normally this cancels out the complexity problem.
Merely storing all the positions that are unwinnable—regardless of why they are so—would require more matter than we have in the solar system. Not to mention the efficiency of running a DB search on that...
The storage space problem is insurmountable. However searching that kind of database would be extremely efficient (if the designer isn’t a moron). The search speed would have a lower bound of very close to (diameter of the sphere that can contain the database / c). Nothing more is required for search purposes than physically getting a signal to the relevant bit, and back, with only minor deviations from a straight line each way. And that is without even the most obvious optimisations.
If your chess opponent is willing to fly with you in a relativistic rocket and you only care about time elapsed from your own reference frame rather than the reference frame of the computer (or most anything else of note) you can even get down below that diameter / light speed limit, depending on your available fuel and the degree of accelleration you can survive.
I would think it would be possible to cut the space of possible chess positions down quite a bit by only retaining those which can result from moves the AI would make, and legal moves an opponent could make in response. That is, when it becomes clear that a position is unwinnable, backtrack, and don’t keep full notes on why it’s unwinnable.
This is more or less what computers do today to win chess matches, but the space of possibilities explodes too fast; even the strongest computers can’t really keep track of more than I think 13 or 14 moves ahead, even given a long time to think.
Merely storing all the positions that are unwinnable—regardless of why they are so—would require more matter than we have in the solar system. Not to mention the efficiency of running a DB search on that...
Actually, with proper design, that can be made very quick and easy. You don’t need to store the positions; you just need to store the states (win:black, win:white, draw—two bits per state).
The trick is, you store each win/loss state in a memory address equal to the 34-byte (or however long) binary number that describes the position in question. Checking a given state is then simply a memory retrieval from a known address.
I suspect that with memory on the order of 10^70 bytes, that might involve additional complications; but you’re correct, normally this cancels out the complexity problem.
The storage space problem is insurmountable. However searching that kind of database would be extremely efficient (if the designer isn’t a moron). The search speed would have a lower bound of very close to (diameter of the sphere that can contain the database / c). Nothing more is required for search purposes than physically getting a signal to the relevant bit, and back, with only minor deviations from a straight line each way. And that is without even the most obvious optimisations.
If your chess opponent is willing to fly with you in a relativistic rocket and you only care about time elapsed from your own reference frame rather than the reference frame of the computer (or most anything else of note) you can even get down below that diameter / light speed limit, depending on your available fuel and the degree of accelleration you can survive.