My audience wasn't students, but my colleagues, most of whom are better programmers than me (which isn't surprising, as I have no formal training in programming or computer science). I work with them every day, and know them well enough to know when they have understood something well enough to implement it themselves.bob wrote:Listening to someone explain a parallel search is _FAR_ different from going out and implementing one yourself. Remember, I talk about this kind of stuff all the time. But when it comes assignment time, everything they understood and asked intelligent questions about in class disappears somehow. So someone sitting in the audience and nodding "yep. uh-huh, yepper, I see, etc does not mean they are going to be able to go out and actually deal with all the dozens of details necessary to do a parallel alpha/beta search.Tord Romstad wrote:About one year ago, I gave a one-hour lecture to my colleagues, where I explained how Glaurung's parallel search worked. The audience had rather mixed backgrounds, like mathematical logic, cognitive science, psychology, computer science, and plain software engineering. None of them had ever implemented alpha/beta before, although a couple of them recalled having seen the algorithm in textbooks. I explained negamax, alpha-beta pruning, and the importance of good move ordering, and why the most obvious ways to parallelize alpha/beta are very inefficient. I proceeded to explain YBWC and the helpful master concept, and how my implementation in Glaurung works. Nobody seemed to have any problems understanding the lecture. I got lots of intelligent and interesting questions, and even a few suggestions for possible improvements.
A parallel search isn't even necessary for writing a strong chess program. I also don't agree that it's terribly difficult, as long as good speedup on a small (<= 4) CPUs is enough. A plain implementation of YBWC is just a couple of hundred lines of very straightforward C code.I've done tons of parallel algorithms over the past 30 years, none come anywhere _near_ the complexity of a good parallel search.
I don't have much programming experience, but I think most of what I have done (mostly symbolic mathematics, knowledge-based engineering and computational geometry, and server software with huge workloads) feels much harder than chess engine programming.
I think othello doesn't differ significantly from chess in terms of difficulty. Chess is certainly more work, but not more difficult work. Othello is clearly better as a pedagogical exercise, as the extra work involved in chess has very little educational value from a programming point of view.I've done an othello project in an AI course several times. Othello is far simpler to program than chess since there are no irregular moves of any kind. And it turns into a significant programming project over the course of a semester. And it is trivial compared to chess.
I don't see how it is different from any other use of a hash table. It's just a matter of storing what you want to remember, and looking it up again when you need it."hashing itself is understood" I would agree with. But using it to reduce the search effort, store best moves and then use them later, and such become complex details that nobody will have experience with the first time around.
Thanks to the Internet, everybody has ready and instant access to have their questions answered.If you are thinking about a case such as where a student can "live" in my office to ask questions, and develop a program quicker, I would agree with you. But if someone is not located where they have ready and instant access to have their questions answered one-on-one, then I believe the project becomes far more difficult...
It shouldn't take many minutes to find dozens of 20-line pseudocode listings of PVS with recursive null move pruning.Again, the "null-move hypothesis" is pretty easy to grasp once it is explained. But implementing it in an alpha/beta recursive program is not exactly trivial the first time around without help.
Remember that I am not talking about winning world championships, but about playing strong chess from a human perspective. You can get quite far with a very crude evaluation function. Material, mobility, passed pawns, king shelter and pawn structure is easily enough to get master-class strength.I have talked to _many_ strong chess players over the years that also program, and they always want to know how this is done. It seems logical and natural to me, but not to a chess player. "Why can't you consider what pieces are controlling that square?" and such questions. It is a very delicate balance of capability vs cost that experience helps to understand.
10,000 lines of C code is a fairly small program by modern standards, but very big for a good starting chess program. Viper, the program I wrote to serve as a simple demonstration of YBWC a few years back, ways in at 4,600 lines of code, and it is actually far too complicated and contains lots of advanced stuff which should be removed (like special evaluation functions for KR vs KP). I think it would be easy to reduce the size by 50% without sacrificing more than 100 Elo points (the current version has strength comparable to Crafty 20.13 and Arasan 10 on the CCRL scale).I am not sure such knowledge can be transferred to a beginner at a 100% confidence level. Or even at a 50% confidence level. A good starting program is probably going to be at least 10,000 lines of code, and most newcomers have likely never written anything within a factor of ten of that size. The first compiler I wrote, as an undergraduate, was just under 2,000 lines total, comments and all...
Each new version doesn't get easier, it just gets stronger. I use roughly the same amount of time each time I do a complete rewrite of my program, but every new program is stronger than its predecessor.But how long have you been doing this is the question? Each new version gets easier and easier. But #1.0 is a challenge.
I don't have time to participate much more in this discussion, but it is all really so obvious that there is hardly any point in discussing it: Looking at the numbers is enough. There are hundreds of master-class chess engines, and just a handful of chess GUIs, despite the fact that hundreds of thousands of programmers around the world are taught UI design, and almost nobody is taught chess programming. Those of us who have done both (see also the post by HGM in a thread on a similar topic in the "Programming and Technical Discussions" sub-forum) generally agree that writing a GUI is much more difficult. Moreover, our GUIs are usually of a vastly inferior quality compared to our chess engines (and my own GUI, regrettably, is no exception).
Tord