woah what a discussion
Chess will never be solved, here's why

#1788
page 127, line 5
Page 127, line 1: "In the best case - a game that is provably winning - the search only has to explore roughly the square root of the search space: a single move at winning positions and all moves at losing positions. This means that a proof of the game-theoretic value of checkers might require a search of as few as 10^9 positions".
#1787
No: read number of positions = time in nanoseconds
When the engine considers 10^9 positions in one second, then it takes 10-9 seconds = 1 nanosecond per position it considers
The engine generates 10^9 positions in one second without considering them. Considering needs a little longer.
#1796
From the above source:
"A node, in turn, is a chess position with its evaluation and history"
The source also says 'consider', not 'generate'
Please provide your source of the contrary.

#1794
The two references quoted #1784 are more recent than the reference #1788.
So the same, page and line.
You said that, not me:
#1785
I had this from this publication:
10^9 positions out of 10^18
http://library.msri.org/books/Book29/files/schaeffer.pdf
10^7 * 10^7 = 10^14, would be an exponent 0.67
#1799
In the conclusion:
"A database containing a proof tree for the game may contain as few as
10^9 nodes—a small number by today’s standards. Strongly solving the game will
be much harder, since it requires knowledge of all 10^18 legally reachable positions
in the game."

#1799
In the conclusion:
"A database containing a proof tree for the game may contain as few as
10^9 nodes—a small number by today’s standards. Strongly solving the game will
be much harder, since it requires knowledge of all 10^18 legally reachable positions
in the game."
Don't pretend to not understand
Now can I ask you where did you find that, to solve checkers, only the square root of the search space has been checked?

Earlier: (and more than once)
"FLOPS are floating point operations per second. That is like dividing the square root of 2 by pi. Such floating point operations play no role in chess."
How could the speed of the computer not play a role in 'chess' ?
Is the suggestion that 'FLOPS' are technically removed from the speed of the processor?
That they wouldn't pertain to the so called 'nodes' ?
If so - that needs to be brought out.
And if there's some other 'speed' that pertains to Nodes then that has to be brought out too. Not concealed.

The square root exponent is dependent on games being highly directional, in the sense that when white avoids the majority of options on his move, the game isn't going to return to that set of positions at some later stage.
This is strictly true of the opening phase of checkers before any promotion - because pieces move forwards only (and material for each side is non-increasing) until promotion. I think it is also true of games with a decisive result (because you can use distance to mate as a metric that only goes in one direction). So if chess is a win for white or black, I would accept it as reasonable to expect a square root exponent.
However, it fails to necessarily be true in games where you reach large classes of positions which are drawn and where there is no directionality - in the sense that optimal play has cycles, and there is no notion of distance from the end. It's interesting to consider an example of such a class of positions in chess which also forms a game like chess that could be analysed. My example is the set of tablebase positions KQkq where there is not a win for either player. I assert that you can't solve a game starting from some drawing example using as few as the square root of the number of positions. The intuitive reason is that neither player has quite enough control. One way to achieve it could be to stop two of the pieces moving. I challenge anyone to find a strategy to achieve that!
It would be an interesting challenge to find a drawing strategy for each side with a relatively small number of positions from the total which is somewhat smaller than 64 * 63 * 62 * 61.
The point of this toy game is that the solution of chess is like a product of solutions of such game for each class of drawing positions (where optimal play has cycles through all positions) plus their transitions (plus more to deal with the defending player wandering into losing classes of positions).

'Nodes per second' would not appear to be an objective measure of the computer's speed.
It would be like saying 'cities per second' .... by tygxc's definitions ...
If that's the way its done - perhaps somebody who professionally knows will now announce that - so I can then reply that it shouldn't be that way !
That is of course - if tygxc has presented 'nodes per second' in a way that isn't grossly inappropriate ...
I'm going by his definitions ... and that could be a mistake.

Dear administration of Chess.com site!
Your admirer from Ukraine is addressing you. Our country is now shedding blood because of the war unleashed by the Russian Federation. The whole world supports Ukraine by imposing sanctions on Russia. I ask you to support Ukraine in this difficult time and block access to your site for players from Russia.
Thanks in advance

'Nodes per second' would not appear to be an objective measure of the computer's speed.
It is a measure of speed in an application. Eg as a measure of how long it would take to generate a tablebase or a strategy incorporating a certain number of nodes.
A "node" is a (preferably unique) position.
#1803
Floating point operations cost more time than integer or boolean operations.
That is why for most problems like forecasting the weather with Navier-Stoles equations which involve floating point operations FLOPS is a measure for the speed of a computer in such floating point operations.
Chess has no need for any floating point operations, only the faster boolean and integer operations. That is why nodes per second is the right measure of speed for solving chess.
#1787
No: read number of positions = time in nanoseconds
When the engine considers 10^9 positions in one second, then it takes 10-9 seconds = 1 nanosecond per position it considers