Arena - the eternal question.

[Mithu]

[MODERATION]
Five posts below this one, which had no on topic content were removed.

Miguel

Its really sad to note that what started as a simple request for an update to Arena 3 became a thread for one-upmanship and insinuating posts.
Just a thread above or below this one is a thread titled Don Dailey, and his life is a glaring example of simple living and high thinking. Why are we nitpicking others when we know that ultimately its all about love? How people remember you after you are long gone is something you must be worried about; not how many features your GUI has or how many updates you have released.
What will our children think of us if they read this thread in the future? I know it is difficult to shed anger but then that is what we are born for - to behave as humans!
I request Arena and Winboard Authors to leave animosity behind and serve their fellow chessmen with unconditional love and friendship. Leave your legacy in our hearts, not in our minds where it may fail our memory and whither away. Computer chess deserves that level of open-mindedness to move forward. Don't be like the proverbial frog in the well and close the doors to a fantastic universe - one that has lots of things for every one of us.
Existence, Nature, Destiny call what you may but I sure that all of them wanted you to behave otherwise. Not as you did in this thread. Set an example for others.
You may have accomplished many great things in the programming world but unless you rise and touch our hearts you will be just another memory when you pass. Choice is again, yours.

In case I have said anything wrong I apologize in advance. And if this posts did stir an iota of feeling, I hope to see not a single post of hatred that the mods would have work to do.

[Giorgio Medeot]

So I really don't see what advantage it would have to put a real frame around it, if a 'virtuall frame' already behaves practically identically. It doesn't offer anything extra you can do, it just makes it impossible to take it apart for people that prefer it that way (like me).

Actually, there's a plus in this: while it' true that you can stick the windows together and move them at once as if they where just one, this behaviour is quite erratical, depending on specific windows platform.
This is really Microsoft' fault for being inconsistent in their API behaviour, but that's life. For example, I've a Win7 Pro and, while the feature work well enough dragging windows around the main monitor, if I try to drag onto the second monitor I have, it turns out in a mess, resizing all Winboard's windows at random.
Still, I understand that: 1) it's vitually undebuggable for you if you can't reproduce it (so we should collect a bunch of different flavour of Windows and some spare monitor too for you, before start complaining ). 2) your time is limited and best spent developing other features.

In the end, let me recall that some famous, big software (think GIMP) use the same multiple windows paradigm for very good reasons.

Cheers,

• Giorgio

[hgm]

Indeed, I noticed that on my Win 8 laptop the 'stickyWindows' option behaves weird: when WinBoard opens in the upper-left corner of the screen it works fine, but when I drag it upward if it started in another location, it just leaves all docked windows behind. I suppose this is debuggable; it is just that I didn't have much time to work on WinBoard at all, since I bought that laptop.

The multiple monitors is another matter, as I don't have such hardware at all. But I expect this is just an oversight in the code, that it doesn't take into account the possibility there could be multiple screens at all. I remember someone submitting a patch in this area, these past months. Not sure what it was supposed to solve, but perhaps I should have a look at what was done. It could be a very minor matter to solve it, even if I cannot test it myself. The most important thing is that people report such problems on platforms I do not have, as otherwise there is of course no way I could ever become aware of them.

[Paul Bedrey]

Do either Arena or Winboard support the hook-up of two machines?
I usually play 2 machines against each other with ponder on, making the moves manually myself. Its nice for observing engine playing style but does not provide enough games for statistical significance.

I notice in windows you can create a wireless network linking two computers. At least that is what it says. I've not tried it yet. Maybe this might be of some use.

[hgm]

Do either Arena or Winboard support the hook-up of two machines?
I usually play 2 machines against each other with ponder on, making the moves manually myself. Its nice for observing engine playing style but does not provide enough games for statistical significance.

I notice in windows you can create a wireless network linking two computers. At least that is what it says. I've not tried it yet. Maybe this might be of some use.

This is not something the GUI needs to support. What it needs is connection softwere between the machines, so that one of the machines is set up as a server to run one engine, and on the other machine (where the GUI and other engine are) there is a client that connects to it, to relay all communication. You then just install that client as engine in the GUI. The latter needs never know that the client was not thinking up the moves by itself, but seeking outside advice.

On Linux such connection software is standard, e.g. ssh. It seems there is such a remote adapter available for Windows, specifically for Chess engines, but I forgot who made it and where you can download (it was German). I wrote something myself, to setup my 'big' machine at home when I traveled to Yokohama, to run run it fther in a GUI on my laptop (but did not need to use it, as the loan computers they offered us there were just as fast as my machine at home). Not sure I ever released that, however (because the German thing already existed).

Setting it up can be a hassle, however, as you might have to combat fire walls and other protection mechanisms before your computer can act as a server. So it is often simpler to connect both the engines to an ICS (e.g. FICS), and then match them there. There are many GUIs that allow you to run an engine on FICS. (Certainly WinBoard and Arena, and icsDrone if you don't need a GUI with it.)

[carldaman]

the only fact is that you are misinformed, reading Russian sources again, didn't you learn by now...?

Michael Diosi
http://www.playwitharena.com

Michael,
if you could just add 5-men tablebase adjudication to Arena, that alone may be good enough and worth a new release.

Thanks,
CL

ChessGUI has that feature but I always disabled it because some engines would benefit from it when e.g. unable to deliver mate left on their own devices.

The biggest problem with a lack of GUI adjudication is that many games will wallow around for 50 extra moves in the very common K+R vs K+R ending (not to mention other similar ones) and waste a lot of resources needlessly, instead of simply calling the game a draw.

Arena, as well as WB, lack this much needed tablebase adjudication capability or else they'd be every bit as good as ChessGUI for serious testers. I personally like the look of Arena and Winboard more than ChessGUI, which is not easy on the eyes. Since I like watching the games in real time whenever I can, ChessGUI is not an attractive option.

[Modern Times]

I play all my games now with adjudication turned off. Yes you do sometimes get some wasted CPU time, but I can live with that.

I use ChessGUI becuase of the ability to set time in minutes and seconds, and because it supports both chess960 standards for both UCI and Winboard.

For normal chess with just UCI engines and long time control, I will sometimes use Shredderchess GUI.

[hgm]

The biggest problem with a lack of GUI adjudication is that many games will wallow around for 50 extra moves in the very common K+R vs K+R ending (not to mention other similar ones) and waste a lot of resources needlessly, instead of simply calling the game a draw.

WinBoard, however, has the adjudication option 'Trivial Draws'. This will adjudicate KRKR draw after 3 moves, and KNKN, KNNK, KBKN and KBKB* draw after 1 move. Using that option, the 'waste of resources' you mention will not occur. So I don't agree that bitbase adjudication is a "much needed" feature. In fact I side with Gabor, and would argue that serious testers would never use such a feature. Tests wil be certainly be corrupted by adjudicating wins in, say, KBNK or KQKR to engines that would not know how to win these difficult end-games at all. (Which for KBNK, which is 100% won after waiting out the initial tactics, could of course be done by a GUI even without consulting bitbases in the framework of a hypothetical 'Trivial Wins' option.)

More controversial is that 'Trivial Draws' in WinBoard currently also triggers KQKQ, while there are some quite long wins in this end-game (DTM=18, IIRC). I still thought it better to include this, however, because KQKQ is quite common, and long wins in it extremely rare, (the 3-move delay filters out the easy tactical wins by skewers), and games are easily recognizable by their result comment ('XBoard adjudication: trivial draw'). So a serious tester could after the test open the PGN file, and select those games with this result message, to check by hand if there were any dubious adjudications. (The long KQKQ wins are easily recognizable: they all have the losing King trapped near a corner by the winning King.) If selecting on result comment still leaves too many games, they could specifically select on the material combination KQKQ.

What would be really useful is to have bitbases that do not indicate if positions are WDL, but if they are trivially won or drawn. Those you could use for adjudications. But even testing with this adjudication would still would make engines 'lazy'. When you get a win awarded automatically in KQK, why would you care if the engine can actually do it? It will produce strong engines that cannot even win KQBK, as in the Ktulu-Joker game in Leiden, a few years ago. Some engine authors do everything for Elo in the lists, and nothing otherwise.

Of course all this raises the interesting philosophical question whether a GUI authors should implement features that they know are wrong to use, just because some users demand them. (Fixed-depth matches being the most common example of that.) Personally I would qualify that as 'irresponsible behavior'. It feels a bit like selling cigarettes...

[carldaman]

I play all my games now with adjudication turned off. Yes you do sometimes get some wasted CPU time, but I can live with that.

I use ChessGUI becuase of the ability to set time in minutes and seconds, and because it supports both chess960 standards for both UCI and Winboard.

For normal chess with just UCI engines and long time control, I will sometimes use Shredderchess GUI.

Interesting. For testing top engines, all of which are UCI, I also like the Fritz GUI. I only wish FritzGUI could randomly pick openings from a large PGN suite, the way Arena does, but unfortunately it can only load them sequentially.

[carldaman]

The biggest problem with a lack of GUI adjudication is that many games will wallow around for 50 extra moves in the very common K+R vs K+R ending (not to mention other similar ones) and waste a lot of resources needlessly, instead of simply calling the game a draw.

WinBoard, however, has the adjudication option 'Trivial Draws'. This will adjudicate KRKR draw after 3 moves, and KNKN, KNNK, KBKN and KBKB* draw after 1 move. Using that option, the 'waste of resources' you mention will not occur. So I don't agree that bitbase adjudication is a "much needed" feature. In fact I side with Gabor, and would argue that serious testers would never use such a feature. Tests wil be certainly be corrupted by adjudicating wins in, say, KBNK or KQKR to engines that would not know how to win these difficult end-games at all. (Which for KBNK, which is 100% won after waiting out the initial tactics, could of course be done by a GUI even without consulting bitbases in the framework of a hypothetical 'Trivial Wins' option.)

More controversial is that 'Trivial Draws' in WinBoard currently also triggers KQKQ, while there are some quite long wins in this end-game (DTM=18, IIRC). I still thought it better to include this, however, because KQKQ is quite common, and long wins in it extremely rare, (the 3-move delay filters out the easy tactical wins by skewers), and games are easily recognizable by their result comment ('XBoard adjudication: trivial draw'). So a serious tester could after the test open the PGN file, and select those games with this result message, to check by hand if there were any dubious adjudications. (The long KQKQ wins are easily recognizable: they all have the losing King trapped near a corner by the winning King.) If selecting on result comment still leaves too many games, they could specifically select on the material combination KQKQ.

What would be really useful is to have bitbases that do not indicate if positions are WDL, but if they are trivially won or drawn. Those you could use for adjudications. But even testing with this adjudication would still would make engines 'lazy'. When you get a win awarded automatically in KQK, why would you care if the engine can actually do it? It will produce strong engines that cannot even win KQBK, as in the Ktulu-Joker game in Leiden, a few years ago. Some engine authors do everything for Elo in the lists, and nothing otherwise.

Of course all this raises the interesting philosophical question whether a GUI authors should implement features that they know are wrong to use, just because some users demand them. (Fixed-depth matches being the most common example of that.) Personally I would qualify that as 'irresponsible behavior'. It feels a bit like selling cigarettes...

Actually, I agree as well. I was not aware (or maybe I forgot) that WB has a trivial draw adjudication feature, and that is the best of both worlds! I hate it when engines rely on tablebases to substitute for real endgame skill -- it is one of the reasons I like Arena and Winboard, where the games are played out to the end, hence the big problem I had with the trivial draws. FYI, Arena will only adjudicate the 'insufficient material' draws.

This is great to know, thanks!

CL