![[nl]](/mwf/v12/flags/nl.png "Netherlands")
Hmm.... Litteral quote:
But let us not nitpick about the past. The discussion was effective, because I could finally wrestle from you information about about a feature that is still missing, and could be worthwhile to have. Never doing analysis myself I would never think of that. So I go to a place where analysis is big business, like here, to collect ideas, and in the mean time suffer the abuse.
Despite the fact that analysis is useless to me, I added many improvements to WinBoard for analysis mode in the past. All by user request, of course. So is it possible now to set the sign of the analysis score (stm POV / white POV), it is possible to adjust the multi-PV setting by clicking in the Engine-Output window, it is possible to play the engine move by just clicking it (in fact any number of engine moves), it is possible to play null moves...
So it is not that I am reluctant to add any new feature. But some things are more difficult than others, and analysis is not the only application, and I do get lots of requests for improvements in other areas by users that actually appreciate it when you implement them. So I have to weigh cost against benifit, and the fact that you only come up with exclude-moves only as a 5th-ditch attempt, and others praise a GUI as the ultimate solution that does not have it at all, of course does not help much either.
> Well, having to edit files because the GUI refuses to do its job is not what I consider 'user friendly'.
But let us not nitpick about the past. The discussion was effective, because I could finally wrestle from you information about about a feature that is still missing, and could be worthwhile to have. Never doing analysis myself I would never think of that. So I go to a place where analysis is big business, like here, to collect ideas, and in the mean time suffer the abuse.
Despite the fact that analysis is useless to me, I added many improvements to WinBoard for analysis mode in the past. All by user request, of course. So is it possible now to set the sign of the analysis score (stm POV / white POV), it is possible to adjust the multi-PV setting by clicking in the Engine-Output window, it is possible to play the engine move by just clicking it (in fact any number of engine moves), it is possible to play null moves...
So it is not that I am reluctant to add any new feature. But some things are more difficult than others, and analysis is not the only application, and I do get lots of requests for improvements in other areas by users that actually appreciate it when you implement them. So I have to weigh cost against benifit, and the fact that you only come up with exclude-moves only as a 5th-ditch attempt, and others praise a GUI as the ultimate solution that does not have it at all, of course does not help much either.
![[mx]](/mwf/v12/flags/mx.png "Mexico")
> others praise a GUI as the ultimate solution
None of which use the interface for serious analysis of games, I guess?
I still feel sorry if you don't feel appreciated, my main issues were with your attacks against non-Winboard GUIs and people that aren't programmers, but I also feel gratitude for you improving the GUI and implementing features instead of claiming it's the users' fault for not implementing them by themselves.
> None of which use the interface for serious analysis of games, I guess?
As I was referring to Tarrasch GUI, which satisfied all needs of Tomgdrums, there is no need to guess. If in your opinion it is useless for analysis of games, then I wonder what you think it is useful for... Just loading engines, not using them for anything, but just to enjoy that it can be done in such a user-friendly way: browsing to the .exe every time?
![[ph]](/mwf/v12/flags/ph.png "Philippines")
Nice gentlemen discussion ! The bottom-line is, you need a little bit of time to appreciate and understand Winboard better compared to the more user-friendly GUIs. In the long-run, they'll all be the same. As everyone says, it more of preference and familiarity of its features. You use it based on what you want. If not, there's a lot to choose from. Maybe Winboard just needs a better user manual for the lazy ones like me 
. It's only hard at first glance. It's an active development, and HG is always as curious as a user to make any additions to make it better for us. The chess variant feature is no less one of the best. It isn't perfect, as it sometimes hangs when you punch the wrong key/s but in general, one of the best toolkit if you know what you're doing.
But I see that the new WB has an analysis mode/analysis game feature, Isn't this what it's suppose to do? I only used Crafty as it's a native engine. I was referring to the latest source release.
I'm not sure if the ones above are the same, but these features could be related to Wilkin Ng additions a long time ago from xboard v4.2.3.
http://tim-mann.org/winboard/wilkin_ng/
Am I right?
I was tinkering on this one a few weeks ago. I just compiled the last changes. It's just usable with Crafty engine for analysis.
http://kirr.homeunix.org/chess/engines/Denis%20Mendoza/Winboard-WilkinNg-changes4-src+build+crafty.7z
As long as it's feasible, I bet HG can improve analysis capabilities of WB.
Just my thoughts.
Denis
. It's only hard at first glance. It's an active development, and HG is always as curious as a user to make any additions to make it better for us. The chess variant feature is no less one of the best. It isn't perfect, as it sometimes hangs when you punch the wrong key/s but in general, one of the best toolkit if you know what you're doing.But I see that the new WB has an analysis mode/analysis game feature, Isn't this what it's suppose to do? I only used Crafty as it's a native engine. I was referring to the latest source release.
I'm not sure if the ones above are the same, but these features could be related to Wilkin Ng additions a long time ago from xboard v4.2.3.
http://tim-mann.org/winboard/wilkin_ng/
Am I right?
I was tinkering on this one a few weeks ago. I just compiled the last changes. It's just usable with Crafty engine for analysis.
http://kirr.homeunix.org/chess/engines/Denis%20Mendoza/Winboard-WilkinNg-changes4-src+build+crafty.7z
As long as it's feasible, I bet HG can improve analysis capabilities of WB
.Just my thoughts.
Denis
> Maybe Winboard just needs a better user manual for the lazy ones like me
What do you think of the new on-line user guide, at http://www.gnu.org/software/xboard/user_guide/UserGuide.html ? So far this focuses on XBoard, but by now I have converged XBoard and WinBoard so much that a WinBoard version would have to be practically the same, except for the screenshots.
Any feedback would be welcome. Also on the "WinBoard Tutorial" that is included with with the WInBoard binary install (accessible through links in the README file).
> I was tinkering on this one a few weeks ago. I just compiled the last changes. It's just usable with Crafty engine for analysis.
This is not just about being able to make an engine analyze a position in Infinite Analysis, or an automatic Blunder Check feature, users explore the variations, refute them, write their analysis down, search for more alternative lines to be analyzed, crosscheck the ideas of one engine into another, and many other techniques.
As Richard Vida said here, exclude moves is ESSENTIAL for doing that. That means that if the GUI doesn't support the feature, the GUI is unusable for interactive analysis.
That's also a reason no Winboard engine is usable for that, and my guess most top engines went with the UCI protocol (the top Winboard engine is Thinker and it doesn't even support the Infinite Analysis feature - Fritz is not UCI but also supports Multi-PV and "Next Best" which is similar to exclude moves. I guess Winboard was a protocol designed without interactive analysis in mind.)
Well, the problem is that WB protocol was never designed at all. It just evolved from the human-oriented text interface of GNU Chess. And then people have just been adding commands for new features that they implemented in their engines. This is also what would be needed here.
One problem is that UCI does not really implement "exclude moves" at all, but the exact opposit "searchmoves", where you have to list all moves except the one(s) to be excluded. While the feature seems only useful for excluding a few specific moves; if you wanted to search a few specific moves you could just play them.
Actually, I have some difficulty imagining how specifying moves to exclude could be useful: excluding a move that is not the best will have virtually no effect on the search altogether, not even timewise. It seems only useful to do this to a move that the engine would otherwise think is best. So a simple command to the engine to tell it the move it has now should be suppressed seems to cover what is needed quite well. And this could be simply a button-option of the engine (just like multiPV is a spin option). That would make it very easy for existing protocol to provide the required functionality. As soon as the engine gets to a new position in analysis mode, it can create a list of all root moves, and as soon as it receives the command "option kill" it can then strike out the currently-best move, and start a search on the remaining moves. For UCI engines it would mean that Polyglot starts a new search with the "go searchmoves" command as soon as it receives "option kill".
One problem is that UCI does not really implement "exclude moves" at all, but the exact opposit "searchmoves", where you have to list all moves except the one(s) to be excluded. While the feature seems only useful for excluding a few specific moves; if you wanted to search a few specific moves you could just play them.
Actually, I have some difficulty imagining how specifying moves to exclude could be useful: excluding a move that is not the best will have virtually no effect on the search altogether, not even timewise. It seems only useful to do this to a move that the engine would otherwise think is best. So a simple command to the engine to tell it the move it has now should be suppressed seems to cover what is needed quite well. And this could be simply a button-option of the engine (just like multiPV is a spin option). That would make it very easy for existing protocol to provide the required functionality. As soon as the engine gets to a new position in analysis mode, it can create a list of all root moves, and as soon as it receives the command "option kill" it can then strike out the currently-best move, and start a search on the remaining moves. For UCI engines it would mean that Polyglot starts a new search with the "go searchmoves" command as soon as it receives "option kill".
> excluding a move that is not the best will have virtually no effect on the search altogether, not even timewise.
It seems you have never used the feature. As the main move isn't searched at all, there is a speed up, that goes higher and higher as more moves are excluded. If you only included 1 move, all the other ones wouldn't be slowing down the engine, so by this thought experiment it's shown that there is speed-up.
That is, if the third favorite move of the engine is the best one, and the user left the engine to analyze the position in infinite analysis, the engine may find it best in say, 15 minutes. If instead, the user excludes the favorite move of the engine, and the second favorite, the engine may show a higher score for this move than for the other two, in say, 3 minutes. That's a great speed up (though this usually doesn't happen in root positions, but on tail positions of long series of moves that the user is investigating).
Also, this "exclude moves" vs. "searchmoves" discussion is just semantics, for the user there's no difference from "exclude e4 from analysis" to "include all moves in analysis, but e4", it's only different for the GUI, and the implementation wouldn't have any difference for the user if it was different.
Well, I guess I did not express myself clearly. What I meant to say is that if there are moves A, B and C, (in that order preferred by the engine), it would not provide significant advantage to exclude C before you have first excluded A and B. Or to exclude B before you have excluded A. So when move D would be the best, I expect the user to first exclude A, after which B floats to the top. Only then you would exclude B, which now is the engine's favorite of the remaining moves. (Before that, you would not even know that B was the engine's second choice, unless you were in multi-PV mode, and excluding it seems pointless, because the engine could already think it is the worst of the worse.) And if after that the engine switches to C rather than D, you disable that one too. So it seems you would always disable the engine's current preferred move, (in addition to those you disabled before.
I would think it makes a huge difference to the user whether he could indicate a certain move he doesn't want the engine to consider, or whether he would have to indicate (by typing, or entering them) the 39 other moves. OK, perhaps 75% of the moves are silly, but still, having to indicate all 9 that are not silly seems awful. If there is only a single move that you want the engine to search, you could simply play it; it seems the feature is not really needed in that case.
I would think it makes a huge difference to the user whether he could indicate a certain move he doesn't want the engine to consider, or whether he would have to indicate (by typing, or entering them) the 39 other moves. OK, perhaps 75% of the moves are silly, but still, having to indicate all 9 that are not silly seems awful. If there is only a single move that you want the engine to search, you could simply play it; it seems the feature is not really needed in that case.
>So it seems you would always disable the engine's current preferred move
Not in all cases. When analyzing with several engines, there may be some variation that loses outright, that many engines like because they don't see it loses. After the user knows it, he may use a new engine in the position and exclude this move from analysis, which will speed up the search because the engine doesn't need to search this move, regardless of if this move was a favorite by the engine or not, or where.
It's similar to when the engine prunes losing variations like hanging a queen from search, but if it would take them depth 20 to realize the move loses and prune it from now on, the user can exclude the move outright so it will not slow down the engine from depths 1-19.
The Fritz engine doesn't support searchmoves, it has "Next Best", in where the current favorite move of the engine is excluded from analysis, like you said, and it's not as effective. Why? Because in interactive analysis the user doesn't just sit at the root position excluding moves, the user forces and explores the variations, and then, after he has seen them or refuted them, he may come back to the root to ask the engine for a move he hasn't investigated. Then the following happens:
Fritz suggests e4 at depth 20.
User forced e4 and explores it until he is happy with his knowledge of the move.
User goes back to the root.
Fritz suggests e4 at depth 1.
User uses "Next Best" (user wants to exclude the move ASAP).
Fritz suggests d4 at depth 20.
User forced d4 and explores it until he is happy with his knowledge of the move.
User goes back to the root.
Now, the user wants a third move at depth 20, and would like to exclude e4 and d4 from analysis because he has already explored them.
Fritz suggests e4 at depth 1.
User uses "Next Best" (user wants to exclude the move ASAP).
Fritz suggests Nf3.
Now, due to the engine's multiprocessor in-determinism, or because the hash contents are different, Fritz picks Nf3 instead of d4. At this point the user has no way to exclude d4, and will split his hairs every time Fritz wastes time analyzing d4.
At depth 18 Fritz switches to c4, the move that sticks to depth 20, and the one the user would need to investigate.
With searchmoves, the user could have told Fritz to "include all moves but e4 and d4 for analysis" which would have led to c4 being found earlier as time wouldn't have been wasted examining d4. That's a reason a solution that excludes only the current favorite move doesn't work.
> I would think it makes a huge difference to the user whether he could indicate a certain move he doesn't want the engine to consider
Yes, but GUIs supporting the searchmoves feature just allow the user to exclude the move they don't want in analysis, the user doesn't have to be aware of the internals.
Example:
Suppose that an engine besides having the searchmoves feature as it is now, also supports an excludemoves feature that does what we're talking about.
User Shift-Drags e4 on the board while Infinite Analysis is running.
GUI understands he doesn't want e4 searched, and tells the engine "search all moves but e4."
The engine does it, the user gets a second option that reaches depth faster as the engine won't search e4.
Now, the user instead of that, uses the new excludemoves feature:
User middle-clicks-drags e4 on the board (or some other shortcut) while Infinite Analysis is running.
GUI understands he doesn't want e4 searched, and tells the engine "don't search e4."
The engine doesn't do it, the user gets a second option that reaches depth faster as the engine won't search e4.
The user can't tell the difference of one or the other, so he sticks with the searchmoves method. The excludemoves feature isn't necessary.
OK, so the interface is always that the user exclused a particular move. But not necessarily always the engine's current favorite. This could still be implemented by defining a string option "kill MOVE", explicitly specifying the move, sent to the engine. This is easy to implement, because the GUI knows what move the user shift-dragged. (Or whatever would have to be used instead, because Shift is already taken. Double-click drag seems a viable alternative.)
The searchmoves method creates a big problem, because the GUI would have to send all other, not previously disabled moves to the engine. So it would not only have to know which those moves are (which in generally it doesn't), but it would even have to maintain a table of them to keep track of which are disabled, and which are not.
The searchmoves method creates a big problem, because the GUI would have to send all other, not previously disabled moves to the engine. So it would not only have to know which those moves are (which in generally it doesn't), but it would even have to maintain a table of them to keep track of which are disabled, and which are not.
Of course, if you are planning to include a "kill MOVE" feature in the Winboard protocol, so that engine are usable for analysis, that's great, but UCI engines that already support the searchmove feature don't need "kill MOVE".
We talked about this the other day, and I claim that having that table, and allowing the user to see what moves are being disabled, and even being able to enable or disabling them with a single click on the table without having to visit the chessboard, would be a better implementation than what chess GUIs do currently (as long as the top moves from the engine appear in the table).
>it would even have to maintain a table of them to keep track of which are disabled, and which are not.
We talked about this the other day, and I claim that having that table, and allowing the user to see what moves are being disabled, and even being able to enable or disabling them with a single click on the table without having to visit the chessboard, would be a better implementation than what chess GUIs do currently (as long as the top moves from the engine appear in the table).
Well, WinBoard never communicates directly with UCI engines, so that would be a Polyglot problem (to translate the "kill MOVE" to a list of moves for searchmoves).
Ah yes, now I remember. This will be a bit of a problem, though, if the GUI doesn't know which moves are legal. I guess it could request a list from the engine, using the multiPV option. By setting multi-PV to 100 and search depth to 1, the engine would cough up a list of moves as thinking output. Apart from the fact that you would need new UI elements, this would introduce a lot of additional complexity.
> We talked about this the other day, ...
Ah yes, now I remember. This will be a bit of a problem, though, if the GUI doesn't know which moves are legal. I guess it could request a list from the engine, using the multiPV option. By setting multi-PV to 100 and search depth to 1, the engine would cough up a list of moves as thinking output. Apart from the fact that you would need new UI elements, this would introduce a lot of additional complexity.
> the GUI doesn't know which moves are legal.
I see. Shredder Classic knows which moves are legal and keeps them in a list in case the user wants to force moves from there instead of the board (here's letting the engine ordering them by relevance, so the user could shrink the window to only show the top 8 moves or so to save space without losing access to main moves)
((sorry to Banned for Life that the example shows 1.b3 as worst second move))
>By setting multi-PV to 100 and search depth to 1, the engine would cough up a list of moves as thinking output
UCI engines would only need to search to depth 1 in single PV, as they report all the moves that they are searching in an iteration (and the user is shown what move they're currently looking at).
> as they report all the moves that they are searching in an iteration
Are they guaranteed to do that? As that would certainly help. Because then the UCI adapter could collect the moves automatically as a side-effect of having started the analysis, in the first itteration of it. And WB protocol could be extended with a command to make the adapter send the list (while WB engines getting that command would send the list by themselves). In fact WB protocol already has such a command, 'book', except that it is specified to only send the engine's book moves for the current position. And these are then presented to the user in a separate dialog, just like you want.
So it seems that all is really needed is to redefine the meaning of the book command, such that when the engine receives it during analysis (where book would be typically switched off), it would send all legal moves, rather than just book moves. (But this is something that only affects engines and adapters.) And the dialog that presents the moves would have to be made clickable.
Of course Polyglot is game-state aware, so it could reply to the 'book' command even without consulting the engine.
> Are they guaranteed to do that?
Fully UCI complaint engines, yes. There are some by programmers that don't fully implement the UCI protocol and they may be a problem... (for instance, Zappa Mexico doesn't support the searchmoves feature, and seems to report all the moves searched in an iteration only after one second has elapsed in Infinite Analysis).
![[fi]](/mwf/v12/flags/fi.png "Finland")
> (for instance, Zappa Mexico doesn't support the searchmoves feature, and seems to report all the moves searched in an iteration only after one second has elapsed in Infinite Analysis).
The latter is mentioned in the protocol (try not to spam the GUI with full output in the first ~second).
, so I had it the other way around, and actually searching to Depth 1 wouldn't work for most UCI engines?
Well, for interactive analysis, it wouldn't be too much of a problem if the list popped up only after a second. WinBoard could send the 'book' command to the UCI adapter immediately when it enters a new position. The adapter could collect moves from the engine as soon as the latter starts to send them, and stop at the first duplicate, and then flush the list to the GUI.
> This will be a bit of a problem, though, if the GUI doesn't know which moves are legal. I guess it could request a list from the engine, using the multiPV option. By setting multi-PV to 100 and search depth to 1, the engine would cough up a list of moves as thinking output.
Why not simply implement a legal move generator in the GUI? Much easier IMO (and more robust).
> Why not simply implement a legal move generator in the GUI?
It would mean that the GUI has to know the rules of the variant. Considering the number of variants that exist, this is pretty much undoable. So it means that the protocol would have to be extended, so that the GUI could download the rules from the engine. But it would be very difficult to design a syntax for this that is general enough to cover every variant. So it would not be simpler at all, it would in fact be far more difficult.
Apart from this, the GUI could never sort the moves in order of relevance, so that the likely moves will be near the top of the list. Only the engine can do that.
> It would mean that the GUI has to know the rules of the variant.
True. But then how does the GUI adjudicate game on illegal move?
The opposing engine sends "result [1-0|0-1] {Illegal move}".
The GUI cannot adjudicate for games where only the engine does know the rules. But WB protocol allows the engine to claim game results and complain against illegal moves (which are then taken back by the GUI). When the opponent is human, the GUI will obey the engine, but the human usually will know the rules, and complain when an engine is faulty. For engine-engine games it is more tricky, but the GUI can at least 'compare notes' between the engines, and flag when they disagree. If this appears clearly in the PGN result comment (e.g. {legality disagreement} or {result disagreement}), the user can search the PGN files for these messages, and conclude which engine was in the wrong. (The actual result can remain 'Game Unfinished'.) An illegal-move claim is always an engine disagreement, as the opponent provided the move, and both the winning and losing engine are supposed to report the result in WB protocol. 50-move or 3-fold-rep draws can be recognized without knowledge of the rules.
![[us]](/mwf/v12/flags/us.png "United States")
Why couldn't UCI be upgraded to do the same??
> It would mean that the GUI has to know the rules of the variant.
Huh, do people use interactive analysis with chess variants? Because if none of them are going to do it, this could be a "chess-only" feature.
Well, I am only interested in improvements that benefit variants, as I don't care much for orthodox Chess at all, and there already are plenty of alternatives for that. If it was not for the variants, I would never have worked on WinBoard at all. It is just that I needed a front-end for Fairy-Max. I would even oppose the inclusion from patches submitted by others if they could not be made to work across all variants, because they would be likely to interfere with the introduction of similar functionality for the variants at a later stage.
But I think that in most cases this should not be a real problem. Careful design of the protocol and user interface makes it perfectly possible to implement exclude-moves in a rule-unaware GUI. As long as you stay away from abominations like the searchmoves command, where you have to invert what the user really specifies, namely sending the moves that must be searched, rather than those that should be excluded.
But I think that in most cases this should not be a real problem. Careful design of the protocol and user interface makes it perfectly possible to implement exclude-moves in a rule-unaware GUI. As long as you stay away from abominations like the searchmoves command, where you have to invert what the user really specifies, namely sending the moves that must be searched, rather than those that should be excluded.
As Richard Vida said here, exclude moves is ESSENTIAL
Sure. How else could you have taught Critter that Chess was mate in three from the opening position?
Sure. How else could you have taught Critter that Chess was mate in three from the opening position?
I actually scolded myself for that, bad teacher, bad teacher!
It least I should have done that with some test Session File instead of my main one...
It least I should have done that with some test Session File instead of my main one...
Maybe Richard could add an edit session file capability? If not, you can always work on teaching Critter that with best play, the opening position is actually a mate in two for the other side!
> Maybe Richard could add an edit session file capability?
That would be great, and I'd accept having to edit text files if that was the only option to have that.
Editing Session File capability is the ultimate tool for interactive analysis, as not only the user can tag fortresses as drawn, winning/losing positions accordingly (Critter may have the deciding moves beyond the horizon but it's clear all of them lose, working with the Session File to backtrack the score becomes too time taking), and mate in x and drawn tablebase positions precisely (who needs to store 6men TB on disk when one can just tell the engine the results), the user can also adjust the score of tail positions as he likes them (I currently do this in my analysis file effectively, but the engine can't read it).
I don't really know what a session file is, but I understand setting positions that the engine has the tendency to mis-evaluatie as draw or win by hand can be very useful. (My tablebase generator supports that possibility for the purpose of checking uniqueness of solutions of end-game studies: by setting a position on the path of a known solution to draw, you can see if the win in the initial position disappears, or if the now-drawn position can be worked around.)
Would it be useful to incorporate a command for that in the protocol? Next to adding a "kill MOVE" command for root moves that the engine should not search, I could also add a "setscore NUMBER" command, which would instruct the engine to treat the current position as if it had the given score, wherever it encounters it in its search. (Perhaps valid until you leave analysis mode.) WinBoard already has menu items "Adjudicate to white/black" and "Adjudicate draw", which now are only used in engine matches. But in analysis mode, they could be used for defining the position as draw, win or loss by sending a setscore command with a zero or mate score.
Would it be useful to incorporate a command for that in the protocol? Next to adding a "kill MOVE" command for root moves that the engine should not search, I could also add a "setscore NUMBER" command, which would instruct the engine to treat the current position as if it had the given score, wherever it encounters it in its search. (Perhaps valid until you leave analysis mode.) WinBoard already has menu items "Adjudicate to white/black" and "Adjudicate draw", which now are only used in engine matches. But in analysis mode, they could be used for defining the position as draw, win or loss by sending a setscore command with a zero or mate score.
> I don't really know what a session file is
Session File is Critter's implementation of Position Learning. Position Learning means that the engine saves to disk the score and depth of the positions it searches, usually in a finite file similar to a hash table, but in where only PV scores and internal PV scores are saved. This file is preloaded into RAM when the engine is loaded, and the engine should be careful about when it writes and reads from this file, because otherwise it would lead to issues: With Rybka 3 Position Learning, the engine would require Depth +1 to do reads, which would eventually be too high to reach in reasonable time, with Critter 1.4 Position Learning, excluding moves would make Critter wrongly learn that the included moves is best, with Shredder Position Learning, the user couldn't make "jumps" from one position to a distant one without there being conflicts of scores (at the root position there's one score, at the tail position there's another, and the user could either propagate forward the first score, or propagate backwards the tail score; this is undesirable, the tail score should auto-propagate to the root on a "jump"), so there's no standard implementation of this feature.
For Position Learning, Rybka and Critter have a setting "Min Depth", which is the depth that should be reached before stuff gets written to disk.
>Would it be useful to incorporate a command for that in the protocol?
Yes, though this would be alongside learning (the engine would auto-setscore the moves that is has already searched.) Maybe an option of "setscore SCORE DEPTH" would also be useful, the DEPTH number would be used to tell the engine "use this score I give you up to DEPTH, but after reaching this DEPTH, search the move normally", this is for when the user has refuted some variation to say, depth 25, but if for some reason the engine can reach depth 26 on the variation by itself, then it can get a score more accurate than what the user gave it (time would be saved as the engine wouldn't search this move the first 25 iterations).
>But in analysis mode, they could be used for defining the position as draw, win or loss by sending a setscore command with a zero or mate score.
This would work too, though in Position Learning there is finegraining (the engine just reads a score and prunes the move.)
Well, to enter a score and depth would require typing, and thus a popup, and the user could do that as well through an engine option in the Engine Settings dialog. I see little opprtunity to make that easier by adding something dedicated to the GUI. But to use the adjudicate menu items in the Action menu to set win / loss /draw to any depth would be quicker than typing anything, and perhaps still useful in many cases. In the end they could use the same engine option, which does include score and depth, set to +mate / -mate / 0 and 999 by the GUI.
> Maybe Richard could add an edit session file capability?
Coming soon... Also SF writes will be disabled at root when using exclude move feature.
> Coming soon...
Awesome!
>Also SF writes will be disabled at root when using exclude move feature.
So, when using exclude moves, Critter won't write to Session File? Couldn't it do it like Shredder Learning, in where using Exclude Moves isn't different from switching to MultiPV 2 or forcing the moves you're including?
Expected behavior:
Engine searches move A to depth 15
User Excludes move A
Engine searches move B to depth 20
Should be the same as:
Engine searches move A to depth 15
User forces move B
Engine searches move B to depth 19
(Basically, Searchmoves shouldn't be something special and the engine could be able to write at all times.)
It will write all refutations with a known exact score (ply1 from root and below), but will not overwrite the entry for root position.
Note to self: multi-pv behavior with SF needs to be re-tested due to recent changes in root search...
Note to self: multi-pv behavior with SF needs to be re-tested due to recent changes in root search...
Thanks Richard.
> I actually did consider move exclusion once, but I could not come up with a good idea for the interface.
Good excuse :). But even a crappy chess-player like myself considers this feature ESSENTIAL.
> Well, whether you are willing to put up with crappy software is not really relevant to the question if the software is crappy, and if the supplier is willing to fix it, or let you "take it or leave it"!
I don't put up with crappy software. That is why I deleted Winboard from my computer.
I was addressing Uly, in case you didn't notice...
> I was addressing Uly, in case you didn't notice...
Oh I noticed....
> > Perhaps this would be a good question for you all to ponder about: do you know any GUI (commercial or otherwise) which gives you a better deal than take-it-or-leave-it?
> Tarrasch GUI!
> (and even Scid Vs PC)
> Don't need to implement much in the Shredder GUI because it already works so well!
OK, now that we have debunked the myth that Shredder GUI works well and wouldn't be in need of serious bug fixing, let me ask the following question, to prevent that you sell us more turnips for lemons:
Can you give us a link to a place where a feature for Tarrasch was requested, so we can see how long it took before it was implemented?
>> > Perhaps this would be a good question for you all to ponder about: do you know any GUI (commercial or otherwise) which gives you a better deal than take-it-or-leave-it?
>> Tarrasch GUI!
>> (and even Scid Vs PC)
>> Don't need to implement much in the Shredder GUI because it already works so well!
> OK, now that we have debunked the myth that Shredder GUI works well and wouldn't be in need of serious bug fixing, let me ask the following question, to prevent that you sell us more turnips for lemons:
You haven't debunked anything. Uly doesn't agree with you. I don't agree with you.
Shredder lets me do everything I need for playing and analysis and lets me do it easily. Methinks you need to understand the word "debunk" a little bit more before you use it in a sentence.
And as Uly said none of the top engines (strength or for analysis) use the winboard protocol so I don't care how that works in Shredder.
> Can you give us a link to a place where a feature for Tarrasch was requested, so we can see how long it took before it was implemented?
http://triplehappy.wordpress.com/
And I know you aren't going to like the Tarrasch GUI and that is fine. (you don't seem to like any gui but winboard) But don't come back arguing about it. For me and my needs (playing and analysis) it is the second best gui I have found after Shredder. (third is Scid vs PC)
And the creator of Tarrasch GUI does not move fast but he does move and takes into account everything people suggest. He even rebuked one of my suggestions (I was suggesting he not add engine vs engine testing but most people want it so he is going to put it in there).
The fact is that the Tarrasch GUI is unbelievably easy to use. Annotating, playing through games, playing a game and simple analysis are a piece of cake. So I, the end user can focus on chess and not the software.
You can insult me all you want, it does not change the fact that Winboard (and I tried it many times as I believe in giving everything a fair shake) did not allow me to get down to chess activities as easily as the software mentioned above.
> And as Uly said none of the top engines (strength or for analysis) use the winboard protocol
> so I don't care how that works in Shredder.
Ah, so you DO put up with crappy software, if the crappiness doesn't happen to interfere with your (extremely limited) interests! Caught on another lie!
> You haven't debunked anything. Uly doesn't agree with you. I don't agree with you.
Hellllloooo! Anyone awake in there? It claims to support WinBoard protocol, and it doesn't.... That makes it broken... That is fact. So all of you can disagree all you want, that just makes you wrong... Your disagreement alters reality only in your dreams!
Yes, that the Tarrasch page. I had seen that of course. Hence my question.
Now what was the requested feature?
> And the creator of Tarrasch GUI does not move fast but he does move and takes into account everything people suggest. He even rebuked one of my suggestions
Ah, he takes them into account. Fantastic! That will do the users much good. And of course he gives infinitely better service when he rebukes you, than I do when I rebuke you. That goes without saying...
If that is the best you can come up with, it seems you have been feeding us porkies on that one as well!
> You can insult me all you want, it does not change the fact that Winboard (and I tried it many times as I believe in giving everything a fair shake) did not allow me to get down to chess activities as easily as the software mentioned above.
Insult? My, oh my, you are really not used to much, are you?
The point you are missing is that I don't see the slightest reason why I should want to change that fact. So WinBoard is too difficult for you... You like software that offers almost zero functionality, that by great accident coincides exactly with your limited needs. So what? If a bicycle can bring you everywhere you want to go, why try to meddle with the design of a space ship?
Everything you have written so far advertizes that you are not able to judge whether software works or is broken, whether service is good or you are given the run-around, or what is the problem when you get stuck. It would be extremely foolhardy to let anything you say affect WinBoard design in any way. Much safer to throw dice...
> Ah, so you DO put up with crappy software, if the crappiness doesn't happen to interfere with your (extremely limited) interests! Caught on another lie!
Sigh....
If software does what I need it to do better than other software it can't be crappy. sorry no lie there.
> Hellllloooo! Anyone awake in there? It claims to support WinBoard protocol, and it doesn't.... That makes it broken... That is fact. So all of you can disagree all you want, that just makes you wrong... Your disagreement alters reality only in your dreams!
And you continue insults. If Shredder does analysis and playing better than anything else out there at the moment (and for my needs it does) then it isn't broken. Winboard does nothing well for my needs. I don't know why you are myopic about this?
>> And the creator of Tarrasch GUI does not move fast but he does move and takes into account everything people suggest. He even rebuked one of my suggestions
> Ah, he takes them into account. Fantastic! That will do the users much good. And of course he gives infinitely better service when he rebukes you, than I do when I rebuke you. That goes without saying...
>
> If that is the best you can come up with, it seems you have been feeding us porkies on that one as well!
Uh oh, you got me on semantics! he takes them into account and adds them. He did rebuke me. And see that is where you don't get me. He rebuked me politely and even said he understood my request but that I was in the minority. You just get angry and insult. Big difference. You don't rebuke. You get angry and insult. I have seen you do it a lot of times and not just to me. So yeah the tarrasch guy gives better service. He doesn't get angry if someone can not explain a problem in technical jargon. And to be quite blunt his product, (also free) is MUCH better than Winboard for what I want and need. It is really not even close.
>> You can insult me all you want, it does not change the fact that Winboard (and I tried it many times as I believe in giving everything a fair shake) did not allow me to get down to chess activities as easily as the software mentioned above.
> Insult? My, oh my, you are really not used to much, are you?
You should probably think twice before making that kind of judgment about someone you don't know. You have no idea what I have or haven't had to deal with. Nor do you know how much I am or am not used to.
But keep insulting me because I am not a programmer, or you think I am lazy or thin skinned. If that works for you don't stop. Just as I won't stop using Shredder to switch to winboard.
> The point you are missing is that I don't see the slightest reason why I should want to change that fact.
Again, I have never ever said that you NEEDED to change Winboard. I gave you a reason that I could never get it to work for what I need. I don't have time to fiddle with software. I need it to work in a certain way. If it doesn't I will find what does I have tried to be civil (for the most part) regarding Winboard. I know what I need and want from a program. And somehow that doesn't work for you. Fine.
And yet that leads to another insult from you.....
> So WinBoard is too difficult for you... You like software that offers almost zero functionality, that by great accident coincides exactly with your limited needs.
So what if my chess software needs are "limited"? They are my needs. If winboard works for someone else? Great! They have different needs.
Shredder (and tarrasch and scid vs. pc) do not offer zero functionality if they allow ME to function in relation to what I need them to do for chess. It is pretty simple when you think about it.
> Everything you have written so far advertizes that you are not able to judge whether software works or is broken, whether service is good or you are given the run-around, or what is the problem when you get stuck.
This is no surprise! I am NOT a programmer. My life's work is in music. I know about that. And trust me I know good service and civility when I see it.
Angry? I am just amusing myself. You haven't seen me angry yet...
No doubt you will immediately start to cry "insult" again, but the fact is that your statements fall so far outside normal and accepted meaning that communication with you is next to impossible.
If your needs involve only 3% of what the software can, that qualifies as "limited". That is a fact. Not an insult.
If software does not work as advertized, it is crappy. Whether you use it, or the broken part of of it, has nothing to do with it. No one is interested in what you use or not. (Oh dear... Another harsh fact of life you will no doubt take as a grave insult...) A blunt knife will not become a sharp knife just because you only want to slice yello pudding with it.
Ah, so you do not know the meaning of the word "nearly", (and it is another insult to point that out...). I was referring to Tarrasch, as described on its web-page, which is is a project that only very recently can out of its beta state for its first version. According to these pages it does not support engine-engine games, it does not support position search, it does not support engine installation (people have to browse for the exe every time they want to switch engine), it does not support ICS play, ... But of course according to you all that is not really functionality, as it is not something you want to do, as you never get tired of telling us. Words almost seem at a loss to describe that... But fortunately you seem to know the word 'myopic', (and it can't be an insult, as you used it yourself!).
You wouldn't say your performance here, and the way you cry "insult" whenever someone points out a fact that does not make you shine, would give people a good clue?
Again, you offer absolutely NOTHING but whining in a quite long post. I asked a very simple question, what was the feature that was added on request to Tarrasch GUI, as you claimed before and, big surprise: NO ANSWER. Just line after line of babble about how much nicer you are rebuked. Well, learn this, then: the way in which you are rebuked doesn't have the slightest relevance for whether something qualifies as take-it-or-leave-it or not.
It is totally unclear to me what you are doing in this thread, other than trolling. (Oh, help... Insult! Insult!). You offer nothing substantial, do not have the slightest intention to use WinBoard. You have nothing to say on the question of the OP... If you can't bear the idea that I like WinBoard because I am a programmer and can make it do what I want, go suffer in silence, but don't bore other people with it!
I am just amusing myself. You haven't seen me angry yet...No doubt you will immediately start to cry "insult" again, but the fact is that your statements fall so far outside normal and accepted meaning that communication with you is next to impossible.
If your needs involve only 3% of what the software can, that qualifies as "limited". That is a fact. Not an insult.
If software does not work as advertized, it is crappy. Whether you use it, or the broken part of of it, has nothing to do with it. No one is interested in what you use or not. (Oh dear... Another harsh fact of life you will no doubt take as a grave insult...) A blunt knife will not become a sharp knife just because you only want to slice yello pudding with it.
> Shredder (and tarrasch and scid vs. pc) do not offer zero functionality...
Ah, so you do not know the meaning of the word "nearly", (and it is another insult to point that out...). I was referring to Tarrasch, as described on its web-page, which is is a project that only very recently can out of its beta state for its first version. According to these pages it does not support engine-engine games, it does not support position search, it does not support engine installation (people have to browse for the exe every time they want to switch engine), it does not support ICS play, ... But of course according to you all that is not really functionality, as it is not something you want to do, as you never get tired of telling us. Words almost seem at a loss to describe that... But fortunately you seem to know the word 'myopic', (and it can't be an insult, as you used it yourself!).
> Nor do you know how much I am or am not used to.
You wouldn't say your performance here, and the way you cry "insult" whenever someone points out a fact that does not make you shine, would give people a good clue?
Again, you offer absolutely NOTHING but whining in a quite long post. I asked a very simple question, what was the feature that was added on request to Tarrasch GUI, as you claimed before and, big surprise: NO ANSWER. Just line after line of babble about how much nicer you are rebuked. Well, learn this, then: the way in which you are rebuked doesn't have the slightest relevance for whether something qualifies as take-it-or-leave-it or not.
It is totally unclear to me what you are doing in this thread, other than trolling. (Oh, help... Insult! Insult!). You offer nothing substantial, do not have the slightest intention to use WinBoard. You have nothing to say on the question of the OP... If you can't bear the idea that I like WinBoard because I am a programmer and can make it do what I want, go suffer in silence, but don't bore other people with it!
> If you can't bear the idea that I like WinBoard because I am a programmer and can make it do what I want, go suffer in silence, but don't bore other people with it!
Your main problem is that you invent arguments that have never been made.
I never had a problem with you liking winboard because you are a programmer. You had a problem with me not being a programmer.
> Again, you offer absolutely NOTHING but whining in a quite long post.
And again, I have apologized already more than once for not being able to accurately or technically describe why I had problems with loading and using engines in winboard.
>> Nor do you know how much I am or am not used to.
> You wouldn't say your performance here, and the way you cry "insult" whenever someone points out a fact that does not make you shine, would give people a good clue?
If you think that this gives you insight into my life. Have at it.
> No one is interested in what you use or not.
I never thought they were. I made a comment (as most people do in forums) about Winboard and how I didn't like it and gave my best reasons. (which I admitted were lacking in details)
Do you see the pattern? You keep making stuff up or inferring things that are not happening? But keep going. It is fun watching you troll.
> Ah, so you do not know the meaning of the word "nearly", (and it is another insult to point that out...). I was referring to Tarrasch, as described on its web-page, which is is a project that only very recently can out of its beta state for its first version. According to these pages it does not support engine-engine games, it does not support position search, it does not support engine installation (people have to browse for the exe every time they want to switch engine)
And yet it is still easier to use than winboard!
>> Again, you offer absolutely NOTHING but whining in a quite long post. I asked a very simple question, what was the feature that was added on request to Tarrasch GUI, as you claimed before and, big surprise: NO ANSWER.
Okay here is an answer (which you will ignore like you do most of our conversation.)
The Tarrasch developer said he would institute the ability to analyze without seeing the engine's move choice but only its evaluation. Users have been clamoring for him to add engine vs engine, which he is also going to do.
Of course this answer won't suffice for you.
> Angry?
Well by all means let me see you angry....
Maybe you could channel some of that energy into building a useful GUI for engines that matter... (see now, I meant that as an insult)
> (see now, I meant that as an insult)
I don't know if you realize it, but basically everything you have written so far in this thread serves no other purpose than to insult. (If not directed against person or program, then at least against intelligence.
) It is just that you are not very good at it that makes it helpful to explicitly announce it.> I never had a problem with you liking winboard because you are a programmer.
Well, since that is what this thread was about, what are you doing here?
> You had a problem with me not being a programmer.
Talking about inventing arguments.... I don't have a problem that you are not a programmer. You have! All I said that if you are not a programmer, it is your own fault. You seriously want to claim that I should have said that if you are not a programmer, it would be my fault???
> I never thought they were.
Ah. So you keep repeating it ad nauseum for what purpose, exactly? Is it your goal in life to bore people to death?
> And yet it is still easier to use than winboard!
So is my toilet.
Do you see the pattern? We are discussing Tarrasch, which had nothing to do with WinBoard, and when the discussion does not go in a direction that pleases you, you immediately fall back to attempts to drag WinBoard down. Are you really that obsessed by it?
> Okay here is an answer (which you will ignore like you do most of our conversation.)
> The Tarrasch developer said he would institute the ability to analyze without seeing the engine's move choice but only its evaluation. Users have been clamoring for him to add engine vs engine, which he is also going to do.
> Of course this answer won't suffice for you.
On the contrary, this is just the answer I need. So he is going to do it, right? Meaning he hasn't really done it, at this point in time, right? Just so that there is no misunderstanding under those readers you have not bored away yet about your interpretation of the concept truth...
![[nz]](/mwf/v12/flags/nz.png "New Zealand")
Thank you tomgrdrums for supporting my program in this argument! I have also replied directly to HG Mueller. Please be assured that I do like your suggestion for "showing evaluation without supporting lines". I have been thinking about how to add it to Tarrasch. One day I am sure it will make it into the program.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill