This is part II (experiments) of a 2-part paper about a new, non-minimaxing, approach to search in game-trees such as Chess and Go. Its first point is that minimaxing is NOT the best decision-making (i.e. chess-move-selection) process based on inexact merely-statistical estimates about the "goodness" of the chess positions at the leaves of a search tree. Its second point is that going down the game tree to some fixed depth, then stopping, is NOT the best choice of chess-positions for your search to explore. "BPIP search" is a way to make better decisions based on any particular search tree, and a way to grow better trees to explore. As of year 2026, BPIP still has not yet been used by chess and go programs, but if were might enable them to get substantially stronger. Would it? I would like to know, but never found out because I abandoned my attempts to write strong chess and go programs as just too difficult a programming task for me. However in this paper we did program BPIP and alphabeta gameplayers for a number of simpler games, achieving strengths apparently stronger than any human and also among the strongest year-1995 computer programs. For some games BPIP indeed outperformed alphabeta, sometimes hugely. Games large enough that full solves of game positions are usually out of reach, and which can have "smart and slow" position evaluators, and in which large searches are done, are the games favoring BPIP versus alphabeta.

I originally wrote this paper and put it on the internet in 1995, and at that time "Monte Carlo game tree search" and today's highly advanced selective alphabeta variants did not yet exist, computer chess was weaker than the best humans, and computer go far weaker than decent human amateurs. Later, go programmers invented "Monte Carlo game tree search" which can be regarded as a "poor man's BPIP" (although the MCGTS inventors did not realize that). MCGTS has been used in go programs with great success.