I'm sorry that this thread has gone so far off track, GCP. It was a very interesting initial post, and not too much after that. I hope I can get this back on track.
Gian-Carlo Pascutto wrote:A train of thought I wanted to post in the DS thread, but which is probably worthy of a separate topic.
I see Ippolit in the same way as Fruit. It creates a new gold standard for engine development. If you write a new engine, you should study Ippolit inside out and consider it the reference of how to do things. The same thing happened with Fruit. The result was that any new engine was on average several hundred ELO stronger than was the case before Fruit.
I don't think Ippolit will ever match Fruit in terms of influence. Before Fruit, everyone was trying to make their evals as big as possible, without spending all that much time testing and tuning. The influence of Fruit was to thoroughly test everything (to be very bug-free), and keep the eval simple enough to be reasonably tunable. Tord should also get some credit for this philosophy.
Rybka also created a paradigm shift IMO in their testing strategy. The idea of running ultra-fast games in order to get as many as possible seems simple, but the common knowledge was that such games would be total nonsense and wouldn't help at all. I remember Vincent saying a few years back, "Do you think commercial programmers test at 1+0?" Nowadays, I don't know anybody that even tests that slow.
There isn't really anything paradigm-shifting in Ippolit IMO. It LMRs like crazy, but I think this is really just an extension of Fruit's PV-centric search strategy.
One other reason I don't think it will become a "gold standard" is that the code is really really ugly. Even the Robbolitos.
It also created the unfortunate situation that any new engine looks a lot like Fruit. There was a thinning of original development and ideas. (Not sure how to say that properly in English)
I am sure that Ippolit will accomplish the same.
Maybe this is a good thing, and it's a kind of natural selection of ideas. But it's also a fact that any alternative approach will have a formidable baseline to meet before it can be considered. Without the Fruit or Ippolit sources out, there was more breeding ground for new ideas.
Computer go was going in the wrong direction for years, it took some very stubborn people to go the other direction for 10 years before they could meet the gold standard from the wrong direction and leapfrog over it. Now the opposite is happening: if you're not an UCT-like Monte Carlo with patterns playout based program, you're too weak to be relevant. But your approach might be the right one.
The chess paradigm has been to make an as fast as possible alpha-beta searcher with selectivity and heavy leaf pruning, and as much evaluation is practical. This has been remarkably stable over the last, say, 20 years. The extremities to which the approach has been pushed are amazing.
Well, I agree. I don't think that AB is necessarily the best way. I've actually been experimenting with a couple of non-AB ideas that show some promise. One very nice side effect is that parallelization is much easier. So get ready for another paradigm shift.
I think there was a paradigm shift when magic bitboards appeared. They are efficient enough that they make any other approach just look wrong. However board representation is not that defining for program strength. (This might be quite subjective)
I disagree there, just because I don't use magic bitboards.
There were a ton of bitboard techniques that were invented in the same time period that could be considered paradigm-shifting when taken together. Anything but rotated really
What are, in your opinion, the odds we will see another paradigm shift? What might be a trigger?
I have some hope big manycore cpus (much more than 100 cores) might cause it. Maybe someday someone makes a workable, strong GPU program. I believe that to accomplish that, a paradigm shift is needed.
Agreed.
