[computer-go] .. if Monte-Carlo programs would play infinitestrong

[Chrilly]

>
> Eeh, am I missing some point here or would not any Go program that uses 
> search and infinite computer power "simply" SOLVE the game - given that 
> scoring is done right and infinite loops are ruled out?
>
The question should be more precisley stated as: Is playing strength a 
strictly-monoton increasing and unlimited function of computing power. But I 
thought the meaning of the question was clear.
Current standard programms would not play infintie strong. Most of them have 
no global search. One could argue that one could then make their local 
searches as a global search. But they are not designed to do so. It would be 
another design. E.g. Handtalk plays on my PC each move within a few 
milliseconds. I assume it played on the original 0x286 within a few seconds. 
Handtalk does not know what to do with addtional processing power, beside 
playing faster.

If the INTEL engineers would design an infinite fast Pentium Fritz and the 
other chess programms would use without any modification this computing 
power and they would search to the end of every game, being (besides bugs) a 
perfect minimax-player. The would have probably overflows in the search 
stack, because they assumed that the maximum lenght of a variation is eg. 
256 Plies, or the node count would behave crazy. But this are technical 
details. Most current Go programms would not play "as is" perfectly.

Note that a perfect minimax-player is not necessarily the best possible 
player. A minimax player assumes that the opponent has the same knowledge. 
They play only optimal against another perfect player. But against an 
opponent making errors such a strategy is in general not the best. E.g. a 
perfect player does not setup traps, because a perfect opponent would see 
the trap. But thats another question. I have written an article (in German) 
about this question. The article can be found at: 
http://www.lbremer.de/chrilly.html

> If we had infinite computing power Go would resemble tic tac toe from a 
> programmer's perspective. period.
>
See above.
Chrilly