Winboard Forum

Hi,

Before purchasing the new fruit, I had a question for anyone who already has it. When I start fruit 2.1 from the command line and enter the following commands:

uci
position startpos
go infinite
...
stop

fruit doesn't stop. Neither does the windows build of glaurung-mainz. Some uci engines that do work this way are zappa and ufim. Does anyone know if the stop command works with fruit 2.2 (in a console)?

Also, does anyone happen to know if fruit 2.2 obeys the "nodes" constraint of the go command? (e.g., go wtime 300000 nodes 1000) Fruit 2.1 doesn't seem to obey it, while glaurung does.

I understand it's not so important an issue, since most people use uci engines in guis. But I'm still curious

Michael

P.S. Interestingly, when I compile fruit myself using cygwin, stop seems to work. So it's some kind of compiler or library issue.

Michael Yee wrote:Hi,

Before purchasing the new fruit, I had a question for anyone who already has it. When I start fruit 2.1 from the command line and enter the following commands:

uci
position startpos
go infinite
...
stop

fruit doesn't stop. Neither does the windows build of glaurung-mainz.

Hi Michael,

I really don't know what is wrong. All I can say is that Fruit and Glaurung both handle the 'stop' command correctly in Mac OS X and Linux. As you say, it is probably a compiler or library issue.

Also, does anyone happen to know if fruit 2.2 obeys the "nodes" constraint of the go command? (e.g., go wtime 300000 nodes 1000) Fruit 2.1 doesn't seem to obey it, while glaurung does.

No, Fruit 2.2 also doesn't obey the "nodes" constraint. It also isn't quite true that Glaurung obeys it. Glaurung checks whether the search should be aborted only every 20000 nodes. If you send "go nodes 1000", it will still search 20000 nodes before it stops. This little problem can be fixed quite easily by modifying the source code, though. Just change line 80 of root.c to the following:

Code: Select all

  RootSearchInfo.nodes_between_polls = min(20000, RootSearchInfo.node_limit);

I'm surprised that there is any support for "go nodes" in Glaurung at all, by the way. I can't recall having written this code at all.

Tord

Hi Tord,

Thanks for the info and tips! It's funny that you don't recall implementing "go nodes" in glaurung, since I'm pretty sure it works (at least approximately as you describe). However, the constraints for depth and maxtime don't. (Or at least I can't figure out a combination of parameters for the go command to get these limitations to work.)

In case you're curious as to why I'm curious about these constraints... I've been thinking about a system for assigning a rating to a player based on their performance in a single game (or group of games). It will basically be a regression-like approach with features (independent variables) like:

- % moves with same "true" (depth 12) score as glaurung/100nodes
- % moves with same "true" (depth 12) score as glaurung/1000nodes
- ...
- average difference in score from depth 1 (or time 1s) score
- average difference in score from depth 2 (or time 2s) score
- ...
- etc.

Michael

Michael Yee wrote:Before purchasing the new fruit, I had a question for anyone who already has it. When I start fruit 2.1 from the command line and enter the following commands:

uci
position startpos
go infinite
...
stop

fruit doesn't stop. Neither does the windows build of glaurung-mainz. Some uci engines that do work this way are zappa and ufim. Does anyone know if the stop command works with fruit 2.2 (in a console)?

Hi Michael,

It's a Windows-specific issue. As you might know, file abstraction does not exist in Windows and every single file type requires specific code. On top of that, MS API is cryptic at best (what do mouse events have to do with stdin?).

Of course, engine authors focus on pipes and make sure these ones work. Console is rarely a priority. My excuse is that I can't even compile the Windows code (found in posix.cpp) on my machine, let alone test/fix it.

To answer your question, I use the same I/O code as ever and therefore the problem should still be there. Fix the problem in Fruit 2.1 and I will fix it in version 2.2 :)

Also, does anyone happen to know if fruit 2.2 obeys the "nodes" constraint of the go command? (e.g., go wtime 300000 nodes 1000) Fruit 2.1 doesn't seem to obey it, while glaurung does.

Node limit has not been implemented. I will do before the next update (with TB support).

BTW I'm expecting great things from you, engine or other software ...

Fabien.

Fabien Letouzey wrote:It's a Windows-specific issue. As you might know, file abstraction does not exist in Windows and every single file type requires specific code. On top of that, MS API is cryptic at best (what do mouse events have to do with stdin?).

Hi Fabien,
that's not entirely correct. If you don't mind a blocking call (i.e. you move this stuff to a separate thread) then reading with ReadFile() will work on console handles, pipes and redirected files, with no need for any special code. In fact, everything works the same in POSIX if you replace the above function with read().
Unfortunately there could be a (Win?) bug just in the case we need most, pipes, so I've had to implement polling as well and that actually requires some ad-hoc code for the reasons you mentioned.

Alessandro Scotti wrote:that's not entirely correct. If you don't mind a blocking call (i.e. you move this stuff to a separate thread) then reading with ReadFile() will work on console handles, pipes and redirected files, with no need for any special code. In fact, everything works the same in POSIX if you replace the above function with read().
Unfortunately there could be a (Win?) bug just in the case we need most, pipes, so I've had to implement polling as well and that actually requires some ad-hoc code for the reasons you mentioned.

Hi Alessandro,

I don't mind blocking calls, but I DO mind threads when they are not necessary. IME they're not worth the trouble for I/O only (and I do know about related engine bugs e.g. in WBEC).

If you have working Windows polling code (not just with pipes), I will gladly incorporate it.

Fabien.

I do not understand the reluctance about threads. They are inexpensive compared to a process and you can lower the priority for something that does not need a lot of cycles.

It's probably the simplest way to do things asynchronously.

Why not use my "template" for a threaded input function.
It's easy to follow, at least for me who wrote it
In the readme file there are some explanations for thread dummies (like me).
http://alaricgoth.blogspot.com/2005/08/input-thread.html

/Peter

Hi Fabien,

Thanks for the information!

Fabien Letouzey wrote:As you might know, file abstraction does not exist in Windows and every single file type requires specific code.

Actually, I'm not too familiar with Windows-specific programming. Most of my experience has been with java and matlab--both farther away from the hardware than other "more hard core" environments.

Of course, engine authors focus on pipes and make sure these ones work. Console is rarely a priority.

That's a good point. Occasionally I start engines in a console just to try simple things out (e.g., to see what UCI parameters are available). But if I wanted to write a utility to interact with an engine, it would start the engine in a separate process and communicate through its stdin/stdout anyway.

Node limit has not been implemented. I will do before the next update (with TB support).

Only if it doesn't negatively impact anything else...

BTW I'm expecting great things from you, engine or other software ...

We'll see. I should be finishing my thesis by next year and then I might have some more free time.

Michael

Hi Michael,

Michael Yee wrote:That's a good point. Occasionally I start engines in a console just to try simple things out (e.g., to see what UCI parameters are available). But if I wanted to write a utility to interact with an engine, it would start the engine in a separate process and communicate through its stdin/stdout anyway.

I am not sure who is misunderstanding the other (refering to your "anyway"). Your utility would use pipes and there will therefore be no problems. Only manual testing can lead to a problem.

Forget about the stdin FILE * abstraction. We can't use it for polling because this is missing in the C library (though it exists in C++?). So we have to use a lower-level file API which is what brings problems on Windows.

Fabien.

Hi Fabien,

Fabien Letouzey wrote:I am not sure who is misunderstanding the other (refering to your "anyway"). Your utility would use pipes and there will therefore be no problems. Only manual testing can lead to a problem.

No, there's no misunderstanding. My problem was indeed with manual testing (not the utility which would be fine). I just said it in a confusing way--not purposefully, of course!--due to my lack of experience with these issues. Others here are much more knowledgeable about this kind of stuff.

Michael