Bob, you post a lot here, you're the last one i mean. Note that you didn't run at the time at the 100-500 cpu range, it is obvious whom i mean i'd saybob wrote:Just to be clear, not _all_ university researchers keep results to themselves. I publish everything I do, both here and in the ICGA (among other places). Others do so also.diep wrote:Hi,
non-brute force searching attempts are very interesting to do. I did do a B* attempt using CNS-I (conspiracy number search - must be appealing name to most people here).
Things i stumbled upon:
a) when giving emails to others who tried CNS and/or invented different forms of it (CNS-2) like Ulf Lorenz, i got 0 replies back. I just wanted to compare how diep using CNS search did do versus P.Conners, for example. There is just 0 communication with university researchers. They keep results for themselves (same thing with parallel speedups at supercomputers, yet i can explain why you get back 0 data there, whereas my logfiles at supercomputer i consider public so if you request 'em you get them by returning email).
Yes the trick is simple as i said. All this non-brute force search is from around previous century and start 21th century.bob wrote:I don't see the issue here. Crafty finds this instantly and has failed high twice on it by the time it has used 1/2 second, running on my laptop, not anything bigger...
It is very difficult to be busy with a non-brute force searcher if you can't compare with anyone.
b) Nullmove is a big winner algorithm and CAN get used in CNS. Idemdito in other non-brute force searching attempts. A nullmove simply gives a high confidence level that a path is no good to explore further. This really speeded up my CNS attempt
c) it is very complicated to get an accurate mainline, yes even the best move is very complicated to get. I tend to remember P.Conners wanted 2 different lines with each line above a certain bound in order to call something its mainline. That was quite expensive when i tried, as changing the search window is simply really expensive and it also has the big problem of that you lose significance in your evaluation function. There is really no alternative sometimes other than to recapture a piece that was captured by your opponent.
If you expand a node somewhere in the tree, that INSTANTLY has an effect at which move you pick in the root now, the score of the mainline and what the mainline is.
d) Most disappointing is the fact that you really burn a lot of nodes to hopeless lines where in brute force search you simply get a cutoff.
If a line is silly and far away from our root window, yes even if it is 0.2 pawn, i want to give a cutoff. Yet as we have each time a flipping mainline and score belonging to it, we burn a lot of extra nodes
e) total search depth is disappointing. It is true that forced lines you can see right to the end and instantly. Great for specific tricks. Of course i started testing simple tricks first.
A trick that Diep finds with CNS without burning a lot of nodes is Rxc5 from the Larsen100 testset. Brute force it burns up really a lot more nodes.
3r1rk1/1pq1nppp/p7/2pB3Q/P4P2/1P2P3/6PP/2RR2K1 w - - bm Rxc5; id "GMG1.092";
c1c5
No matter how simple the trick is, it is about the number of nodes you need to find Rxc5 wins because of the trick:
Rxc5 Qxc5 Bxf7+ Kh8 Qxc5 Rxd1+ Kf2 Rxf7 Qh5 Rd2+ Ke1 g6 and now you have to see Qe5+ to see that white wins the rook.
So it is basically a total forced line from blacks viewpoint seen.
Easy for best first type searchers (whatever name you want to give it).
bob wrote:
Yet this was the only 'victory' i could speak about.
All kind of other tricks, real simple ones, were really complicated to find, despite burning way more nodes.
f) memory management is expensive. I used a memory buffer of 400MB, lotta RAM for those days for a single processor. brute force search is much easier. For CNS i had implemented a big tree concept WITH transpositions.
Maintaining that is not so easy. My solution was a stupid one, just to experiment with it, i simply searched until the RAM was completely filled.
then search stopped.
Now as a replacement scheme that is NOT very clever.
All this slows down search bigtime.
A few years ago i didn't find that very acceptable.
It is here where brute force total annihilates all other forms of search most. The combination of more overhead into silly nodes with more efficient search is deadly.
Selectivity you can get in brute force search by forward pruning, reductions and extensions. That's much easier than doing everything in a non-brute force manner.
Amazingly now if you go play games with it, you will typically see that you aren't gonna lose many games based upon missing tactics. It is relative easy to avoid MISSING tactics.
The real problem what loses you game after game is the idiocy that happens around your mainline. It keeps nonstop doubting and changing its mainline. That is really BAD.
This where in a brute force search, the search really corrects diep's bad tuned eval (note i'm busy with a big project with Renze Steenhuisen to improve its tuning a tad at a processor or 40, that will weed out hopefully some historic idiocy from 10+ years ago in diep's eval).
This is however not true for all evaluations. In ancient times, search was simply not needed for fine grained positional corrections. You can see that in rybka also. If you have a real well tuned evaluatoin function, you can risk doing dubious hard forward pruning last 7 ply or so.
That is very complicated as soon as you already add mobility in the way Diep is doing it. Evaluation doubts more. Search IS needed to correct it bigtime last few plies especially.
All this happens in brute force, and alternatives to it, that correction doesn't happen. That is a BIG eloloss.
That aside from that it wasn't capable of finding some trivial tactics which no brute force search misses.
There is ways around finding tactics i tend to believe. Some clever extension here or there. There is no way to compensate for positional eloloss.
Vincent