Dann Corbit wrote:
I think the burning question here is:
"Better for who?"
Now, that introduces another question:
"Who am I building this engine for?"
If the answer is "Myself" and you are the only intended customer, then it does not matter how difficult it is to get it to do things that other customers would want because they are irrelevant. Such is the case for private engines, for instance.
As I see it, there are two chess interfaces which are the most friendly to the customer:
Shredder and ChessAssistant.
Furthermore, both of these companies listen to the customers and follow their feedback and incorporate customer demands into their tool sets.
I don't think that we see these features by accident. They are the features that the customer wants.
If the benchmark is customer base, then I think both Shredder and ChessAssistant pale in comparison to ChessMaster as far as being friendly to customers.
And, as far as GUI vs Engine separation goes, ChessMaster is engineered better. The ChessMaster GUI runs engines by giving them full autonomy. There is a clear delineation between GUI (display) and engine (game logic).
I, as a programmer, am happy with this design, and the ChessMaster users out there are happy with what they get.
So there you go. Friendly to customers, and friendly to programmers.
And since you have mentioned your number 1 software development rule, please allow me to mention one that is also important: "Modelling the real world as closely as possible".
In the human world, you have the wooden board/pieces (dumb display), and you have the human players (game logic). You model that with a GUI and engines.
That is something you can explain even to the most non-technical chess player. Changing the engine is equivalent to changing your human opponent. That to me is better than having to explain that you are not really changing your opponent, just portions of it, because some chess logic is actually on the GUI (the wooden board; shock).
ChessMaster is really very good at this. They associate the engine personalities with well-known human players. And users get that. There is the wooden chess board (which in CM looks like real 3D wooden board), and then there is this choice of engine personalities.
Again, I agree with making customers happy. I also believe that it can be done without sacrificing good engineering designs.
I am looking at the "Import Winboard Engine" dialog right now.
It has the options:
[x] Use Chessmaster Opening Book
Book Name:
[Select]
Command Line Parameters
___________________________
[] Pondering [x] Use Endgame Databases
Pressing the select button gives me a jillion opening books to select from
So it seems that ChessMaster does listen to their target audience.
Shredder has the same set of options engines. But you think that Shredder listened to the customer, while ChessMaster did not?
I have to disagree on this one. For me, as far as UI is concerned, the Shredder UI is a disorganized mess compared to ChessMaster.
In fact, you won't find non-valid words in the ChessMaster dialogs. In contrast, you find things like "PosLearning" (that's one word) in Shredder. What exactly is that? A misspelling of "Post Learning"?
You can tell that the Shredder UI was designed by a programmer and not a User Experience person. The Shredder menu has 'Command', while the ChessMaster menu has 'Action'. There is no real organization in the Shredder menu, so you get 'Extras' for the bunch of unrelated items. Here is an example of real-world modeling in ChessMaster: you see menu items like, Mentor, Move Advice, Chess Coach. In contrast, Shredder has all sorts of words that are hard to relate to human chess (like, Tripple Brain, Histogram).
I'm guessing that Shredder does not have a dedicated UE team, like you have in big software companies (UbiSoft). And that shows in the quality of the UI.
Cheers...
I agree that there are some very nice things about the CM GUI.
I especially like the "human readable analysis" feature.
But the Shredder GUI makes it easily possible for me to do all the things that I want to do, and the CM GUI leaves some of these features out altogether (or at least I do not know how to do them in CM).
Examples:
1. Install UCI engines
2. Analyze a game or set of EPD records and produce EPD output
I guess that you may be right about the Shredder language in the GUI. Everything seemed quite obvious to me, but maybe the average Joe on the street will find CM easier to understand.
Guetti wrote:I think the problem is that your GUI plays chess for him, even if his engine doesn't know how to move.
I still don't get it. Obviously, using somebody else's GUI forces you to live with the limitations and design decisions in that GUI, but nobody forces you to use that particular GUI. It's entirely your choice.
Tord
What if I choose to use the ChessBase GUI which just happens to use (say) Rybka to choose part of the moves? My code will be called to play once we reach move 40.
What if I choose to paste Crafty's entire source code into my own source code, and let it do all the actual thinking until the game reaches move 40? Would be more or less the same, wouldn't it?
Just as an example to show that it is the use of code written by others which matters, and not whether all the game-playing code is located in the same executable.
Tord
As far as I am concerned, from my perspective this has _never_ been about code division. It has been all about code _utilization_.
If your GUI does lots of chess stuff, even to the point of searching the tree, that is fine so far as I am concerned, if and only if nobody else can use your GUI however. If others can use your GUI in a tournament, then I am opposed.
It has been about multiple people using the _same_ chess-playing code, not about where you draw the line between GUI and engine. And, more specifically, at least in my comments, it is specifically addressed to functionality in a GUI that can/will be used by others. If that is not the case, I don't care what does what...
A GUI that is meant to be used as an agent for conducting engine-engine matches should not assist engines in any way. E.g. by telling it how long it must think on this particular move, or on what move it should ponder, or if it knows a good move from an opening library. If engines cannot perform those tasks themselves, they are not functional engines.
An engine-GUI communication protocol meant for general use and compatibility should respect that .
I admit that EGTBs are a problem: for practical reasons we cannot expect tournaments like Chess War to support a few dozen different complete sets of EGTBs, one set dedicated to each engine. There should be a limit on disk and memory usage per engine, and even 5-men EGTBs would exceed any acceptable quota by a large marging. So their seem to be good arguments for a common format of the data tables, which can then shared by anyone.
Nalimov format, however, is not acceptable for this purpose, as its use is restricted by an unfair licence policy.
hgm wrote:I admit that EGTBs are a problem: for practical reasons we cannot expect tournaments like Chess War to support a few dozen different complete sets of EGTBs, one set dedicated to each engine. There should be a limit on disk and memory usage per engine, and even 5-men EGTBs would exceed any acceptable quota by a large marging. So their seem to be good arguments for a common format of the data tables, which can then shared by anyone.
Nalimov format, however, is not acceptable for this purpose, as its use is restricted by an unfair licence policy.
Maybe it is time to create a new, open format for EGTBs and convert the existing Nalimov tablebases to this format, and publish the source for accessing them under a BSD-like license? Then new engines will be able to access the same files, using either the "standard" code, or using their own improved version of that code, or using their own code entirely.
I don't know if the Nalimov file format is legally encumbered, or if it is just the access code that he wrote which is not available under an open license. If the file format itself is not encumbered, that might be even better---it would mean just reverse-engineering the format and doing a clean-room implementation of new code to access it (so that the new code is not derived from Eugene's code) and the result could then be released under an open license.
I don't know what his original intentions were when he gave permission to use that code to a few specific people, but I think enough time has passed that it would be fair to level the playing field with respect to EGTBs, and create an option for accessing them which is equally open to everybody.
A GUI that is meant to be used as an agent for conducting engine-engine matches should not assist engines in any way. E.g. by telling it how long it must think on this particular move, or on what move it should ponder, or if it knows a good move from an opening library. If engines cannot perform those tasks themselves, they are not functional engines.
An engine-GUI communication protocol meant for general use and compatibility should respect that .
I admit that EGTBs are a problem: for practical reasons we cannot expect tournaments like Chess War to support a few dozen different complete sets of EGTBs, one set dedicated to each engine. There should be a limit on disk and memory usage per engine, and even 5-men EGTBs would exceed any acceptable quota by a large marging. So their seem to be good arguments for a common format of the data tables, which can then shared by anyone.
Nalimov format, however, is not acceptable for this purpose, as its use is restricted by an unfair licence policy.
Here's my main issue with a GUI doing EGTB probes: Crafty's "swindle mode". If I am playing an opponent that doesn't support endgame tables, and I reach a 5-6 piece position that is an EGTB draw, I want to maximize my chances for winning in case my opponent makes a mistake. If you just play any EGTB draw, you often play an easy draw rather than a difficult one. For example, KRB vs KR. The KR side can make one of many mistakes and easily lose that ending, but if I instantly play RxR then the game is over. And a GUI will do that.
I have run into this in the past. yes a GUI could do the same thing by finding all the EGTB draw moves, and then telling the engine to just search those moves without using an EGTB, but that is code a user ought to write for himself as there are lots of tricks involved in dealing with EGTBs, including missing ones...
That some people are allowed to use it, while others can't get permission. Also, the license agreements, even if you can get such a license, might be incompatible with the license of the rest of your engine, so that it is no good to you anyway.
hgm wrote:I admit that EGTBs are a problem: for practical reasons we cannot expect tournaments like Chess War to support a few dozen different complete sets of EGTBs, one set dedicated to each engine. There should be a limit on disk and memory usage per engine, and even 5-men EGTBs would exceed any acceptable quota by a large marging. So their seem to be good arguments for a common format of the data tables, which can then shared by anyone.
Nalimov format, however, is not acceptable for this purpose, as its use is restricted by an unfair licence policy.
Maybe it is time to create a new, open format for EGTBs and convert the existing Nalimov tablebases to this format, and publish the source for accessing them under a BSD-like license? Then new engines will be able to access the same files, using either the "standard" code, or using their own improved version of that code, or using their own code entirely.
I don't know if the Nalimov file format is legally encumbered, or if it is just the access code that he wrote which is not available under an open license. If the file format itself is not encumbered, that might be even better---it would mean just reverse-engineering the format and doing a clean-room implementation of new code to access it (so that the new code is not derived from Eugene's code) and the result could then be released under an open license.
I don't know what his original intentions were when he gave permission to use that code to a few specific people, but I think enough time has passed that it would be fair to level the playing field with respect to EGTBs, and create an option for accessing them which is equally open to everybody.
The endgame tables themselves, before compressing, are free for anyone to use as they can't be copyrighted or patented. The problematic part of this is the compression and on-the-fly-decompression and how the accessing is done so that an entire table doesn't need to be decompressed to access the data near the end...
Personally, I have gotten a bit "down" on endgame tables anyway. 10 years ago, they might slow a search from 50K to 10K nodes per second, a factor of 5. Today's processors are far faster while the disks are not, so it might be a matter of dropping from 20-30M nodes per second to 10K which is not worthwhile in general...
bob wrote:The endgame tables themselves, before compressing, are free for anyone to use as they can't be copyrighted or patented. The problematic part of this is the compression and on-the-fly-decompression and how the accessing is done so that an entire table doesn't need to be decompressed to access the data near the end...
Personally, I have gotten a bit "down" on endgame tables anyway. 10 years ago, they might slow a search from 50K to 10K nodes per second, a factor of 5. Today's processors are far faster while the disks are not, so it might be a matter of dropping from 20-30M nodes per second to 10K which is not worthwhile in general...
For chess engines, I think the most useful thing about endgame tables is that you can make bitbases from them. I've been wanting to do some experiments with that for a long time (I guess about 8 years now.. sheesh!) but there is a lot of preparatory work I would want to do first and I'm just not motivated enough to do it. But I do believe that a pretty good lossless, or almost-lossless representation of bitbases is waiting to be found. If they can be made smallish but still randomly accessible, they could be used at interior nodes in the search ala DarkThought. Combined with more general/approximate recognizers, I imagine this could be pretty helpful in navigating from late middlegame into a winnable ending.
Uri wrote:What's the rule of the GUI? Does the GUI improve the program's playing strength?
It should not affect strength at all, but many have "forgotten" this. And so we have GUIs that choose opening book moves, GUIs that play endgame database moves if the position starts off in a known EGTB position, GUIs that decide how much time the engine can use, GUIs that decide what/when the engine should ponder something, and probably other things I have forgotten.
All of which represents a large problem IMHO for compute chess events, where the same GUI is used by several different programs, so that they all have the same opening book code, moves, etc, which is similar to having multiple copies of the same program playing. many opening lines go 20 moves deep, many games are over by move 40, meaning the GUI can be responsible for 1/2 the moves played.
You are mixing two entirely unrelated things here. How tasks are divided between the UI and the engine part of a chess program is a purely technical design decision by the author, and is completely irrelevant with regard to computer chess events. To what extent a program should be allowed to use code written by other people than the author(s) to select its moves is an entirely different question.
Tord
I'm not mixing things at all. This has been discussed ad nauseum in the past, with no real resolution. If a GUI is going to participate in the game itself, rather than just being a "User Interface" (the UI part) then only one such instance should be allowed in a tournament. Time allocation is a tricky and interesting part of the game. Programmers should not be able to use an existing piece of code to handle that. Ditto for opening book move selection which is another very tricky and complex issue.
GUI does _not_ imply all of those things. A user interface is simply an interface that sits between a user and some application, in this case a chess engine. The interface "connects" the two, no more, no less. Xboard/Winboard is a classic example. It does nothing but relay moves between the user and the engine, and display the board... That is a traditional GUI.
It also tells you important things like how much time the opponent has left.
That is really all, and in hand-operated events, I do not use that information anyway since the xboard clock is not the official game clock, and I have my own ideas about how to manage this independent of the GUI.
But the GUI can not tell me anything about the game state that I don't know, and it can't influence how my engine operates whatsoever... by design...
