Daniel Shawul wrote:[...] So what I am trying to disprove is the original proposal by Bob that {return rand()} would give
this effect. I gave 3 or 4 possible theroretical reasons why it shouldn't work and results seem to prove me right.
The minimax is really screwed with this set up. Sensible setup IMO that will not violate standard search methods could be
- using (hash_key % 1000) to avoid differently evaluating a position every time it is visited
I don't think it matters either way.
- Use exact opposite score when side to move changes.
If anyone here proposed having an evaluation function that is essentially (0 + a random bonus for the side to move), I am sure it's a problem of communication, not really what was intended. For instance, in Ruy-López the evaluation function returns scores from the point of view of white, and it's the caller who flips the sign if it's black's turn. So `return rand();' is perfectly OK. Or we could just make the random symmetric around 0 and forget about these kinds of details in different engines.
- By just searching, only one side's mobility eval (if any) is done, nothing whatsover
about the other side's mobility. Don't know how to fix this. At even/odd plies only the
sides to move mobility is conducted. So this violates perfect information game nature of chess
and even adds an artifical "even-odd behaviour" like the one inherent to alpha-beta.
You keep saying this about only evaluating one side's mobility, but it's not right. Imagine a depth-2 search. The leaves get scores picked from a uniform random distribution. The nodes where depth-1 is left get as score the scores that are the maximum of several uniform distributions. The more uniform distributions they get to pick from, the higher the expected score. The root will get a score that is the maximum of minus the distributions for depth-1 nodes. Again, the more moves this has available, the higher the expected score.
It is true that the resulting probability distributions are not symmetric at all, and that "even-odd behavior" will almost certainly be present.
It is very possible that many search modifications that typically result in improvements when using a normal evaluation function will be detrimental when using a random one. For instance, quiescence search may introduce strange biases that aren't helpful at all, and it will certainly waste a lot of time.
Another thing I wanted to comment (although it's in response to someone else in the thread) is that thinking of alpha-beta windows when trying to understand the Beal effect is probably not very helpful. The result of the search is guaranteed to be the same as what you would get with minimax.
Anyway if someone has a clear understanding of what the Don Beal effect is and how it can be achieved
I will test with that setup.
I think `return 0;' -vs- `return -10000+(rand()%20001);' is a good test. Sort the moves at the root randomly. This way you are effectively comparing "move randomly" with "evaluate randomly", but both engines have the ability to detect mate.
Other Observaions:
This random engine is like Chest. Its only hope of finding a win is through
long combinations of moves which lead to mate that happen to fail in its horizon.
We might as well return 0 instead of rand() for eval. And I think that
returning 0 might be better as it allows deeper search. The rand() just slows down alpha-beta.
You see in all of its games it throws material quite quickly...
Get elo of Chest if anyone conducted it, and then take away some elo from it and we may have
an approximation for this thing. No elo coming from rand() if anything it should come from
its mate searching capabilities.. And this is not the Beal effect btw. It comes from seeing the tips
of the tree by search as in Tic-Tac-Toe and not from rand().
I think you didn't understand what I said about tic-tac-toe. Assigning a random value to
draws makes the perfect-knowledge engine prefer moves that constrain the opponent during the game and leave more options for itself. The resulting program makes moves that feel very natural, like taking the middle spot most of the time when going first, even though all moves are draws.
Infact replacing rand() with 0 should
give a better mate searcher.
I think now we have a good test to try. You think `return 0;' will perform better than `return -10000+(rand()%20001);', and I think worse.
