And can you even do that while keeping its UCI functionality like MultiPV or searchmoves? If not, XBoard Stockfish would be an inferior than UCI Stockfish, proving my point.
And the most successful authors chose UCI.
Moderators: hgm, Rebel, chrisw
And the most successful authors chose UCI.
That would indeed be a work-around for when you want to search a specific move, but not when you want to avoid a certain move, and have no idea which move is second-best. You could of course figure this out by running a multi-PV search, but that would make it expensive to reach a given depth, because a lot of time would be spent on searching the #1 move that you wanted to avoid. And you would have to go to high depth, becasue the #2 move might change at that depth.
Oh man. Go argue your pointless dinosaur nonsense with somebody else. The OP asked about EPD/FEN providing history data. I pointed the OP at UCI: "FEN | startpos moves <move1> <move2>" a de facto standard which is followed by all UCI compatible engines, which is mostly all modern engines inc. Stockfish and Leela. I couldn't care less what you or Crafty do. Not interesting. My opinion is that XBoard is past its sell by date. Disagree as much as you like, I could not care less to get drawn into a purposeless CCC war on how many angels can you get on the head of a pin.bob wrote: ↑Sat Apr 04, 2020 7:13 pmThis seems inefficient. What's the point of the original FEN string since the moves contain ALL of the information. Xboard approach is much better. When you want to export a FEN, you have to back up to the last non-reversible move, emit the FEN, then all the moves that follow. Why not just input the entire game, which is what PGN is supposed to do. And, BTW, PGN allows you to provide a starting position using FEN. Which makes this redundant. If your program can parse PGN, you already have this FEN problem solved. Why solve it AGAIN within the protocol interface code?chrisw wrote: ↑Sat Apr 04, 2020 11:36 amI would not use Xboard, UCI is so much better and the documentation way more concise, most 'sensible' people use it, and it's the standard for GUIs and Python Chess. Some old engines still use XBoard and getting some of them to work with Python-Chess for example is a nightmare. I haven't found one UCI chess engine that doesn't run straight out of the box from Python-Chess UI code. UCI documentation download fromLuis Babboni wrote: ↑Sat Apr 04, 2020 2:41 am Thanks Chrisw!
I think I´ll use xboard protocol but sounds very nice that.
My concern is that when I´ll use perft results this will be take in account.
It seems not.... at least not for the moment.
https://www.shredderchess.com/chess-inf ... rface.html
Relevant bits of documentation:
position [fen <fenstring> | startpos ] moves <move1> .... <movei>
set up the position described in fenstring on the internal board and
play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.
Move format:
----------------
The move format is in long algebraic notation.
A nullmove from the Engine to the GUI should be sent as 0000.
Examples: e2e4, e7e5, e1g1 (white short castling), e7e8q (for promotion)
So, for example, in a game the position information string would be (assuming startpos, but could be any FEN)
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4 g8f6
etc etc.
That way, your engine doesn't have to keep track of a game history, all that can be handled in the GUI, the engine acting as a "FEN + moves" solver for each position. Externally to the engine, either use a standard GUI, or write your own simple "game player" with Python-Chess, all very straightforward, tried and tested.
All engines that use UCI format will already be parsing these position strings as standard, btw. As engine programmer, you need do no more than ReadFEN(), leave the FEN pointer looking at the end of FEN string, and if you find " moves ", then parse the moves one by one, adjusting your game board, side to move, history, move number and 50 moverule counter accordingly.
Is that what you think? Amusing...
Of course. Polyglot + Stockfish is a CECP engine that thinks and moves identically the same as Stockfish, right? No problem at all to use MultiPV and move exclusion when you run that under WinBoard.And can you even do that while keeping its UCI functionality like MultiPV or searchmoves?
Yeah. And if Norway was Japan, Stockfish would be a Shogi engine. You have no point.If not, XBoard Stockfish would be an inferior than UCI Stockfish, proving my point.
That's like arguing that all top engines are Winboard because they can be made to support the protocol with an adapter
No, it is constructive proof that CECP is upward-compatible with UCI. CECP must be able to do anything that UCI can, or it would not be possible to run UCI engines under WinBoard without loss of function. OTOH, it is not possible to run every CECP engine without loss of function in a UCI interface. Because UCI does not support draw offering and acceptance, resigning, learning...
Where did you get this silly idea? It is totally detached from reality. The protocol engines use to communicate have no reflection on their internal workings whatsoever. You seem to have no clue at all what you are talking about. How many UCI engines have you written? How many CECP engines?This has always been about the design decisions that developers have to make when programming their engines, how they're different depending on the protocol, and how this that chose UCI had more success than those that didn't. Not about how the inner workings of the engines are identical and the protocol just helps them communicate with the user and GUIs.
This is easy to disprove:
With a good protocol, the protocol should of course not affect the design of the rest of the engine. In UCI I do not think you can easily handle learning, decide how to implement your pondering ... . For me the answer was Xboard but of course my engine is very bad and not a Stockfish clone. If it was I would certainly have chosen UCI and my engine would have been very good like most of the other UCI engineshgm wrote: ↑Sat Apr 04, 2020 10:09 pm Total bullshit.
That an engine is UCI does not mean it implements MultiPV or searchmoves. Most UCI engines in fact don't. And some CECP engines do. In Dutch we would say: "Je lult uit je nek!".
Random changes because of the butterfly effect do not count as an effect of the protocol. Especially if they only exist in you dreams. They would count as an effect of randomness. If I I throw a 6 at dice, I cannot blame it on Julius Caesar, even though most likely it would have had another outcome if he would have said something different when crossing the Rubicon!
It baffles me that someone can even think the choice of protocol would affect the design of the rest of the engine. As both protocols do precisely the same: load the engine with a position and / or game history, tell it when, and how long or deep it can think, and how many resources it can use, whether they should consult their own book, where to find EGT files. They just do it in a slightly different format. Do you have no clue either as to how the protocols work?
If you absolutely want to track a game, of course that's possible with UCI as well with a few lines of code. Most GUIs should transfer "ucinewgame" for starting a new game, and the engine surely can tell whether it has a big advantage or disadvantage, i.e. whether the game was won or lost.
UCI doesn't even specifiy that. You can do what you want during pondering - it's just that if you decide to ponder on something other than your announced pondermove, you don't tell that to the GUI.decide how to implement your pondering