Editing tscp

[hgm]

If I remember it barely supports the Winboard protocol (and only v1 I think) so improving that is also something you could do, if you had spare time.

--Jon

Indeed. Basically the only thing that is needed to make it v2 is print

feature done=1

in response to

protover 2

That already solves the annoying 5-sec waiting period you would have on most GUIs when starting up the engine. If the intention is to run the engine on non-Windows systems it would be helpful to make this

feature sigint=0 done=1

to suppress the SIGINT that XBoard would otherwise send after each move, and which would kill the engine. This can be done by making the engine ignore SIGINT, but it turns out that when you run windows programs that ignore SIGINT under wine, the SIGINT kills wine nevertheless! So it isbetter to use thesigint=0 method.

[sje]

Adding support for SAN and FEN I/O to tscp would better support xboard v2, but the primary motivation is to make the program more friendly for play vs humans via a console interface. For example, tscp currently has no easy way to set up a position, and this would be fixed with FEN input capability.

SAN would be useful for both human move entry and also for the display of a predicted variation.

Two more edits which would significantly speed up the program without changing move selection logic:

1) Track the location of each king for use when testing in-check status; at present the entire board is scanned to locate a king.

2) Add incremental hash signature updating; at present the entire board is scanned after each move.

And a third to eliminate some evil:

3) Get rid of the setjmp()/longjmp() calls which should never have been allowed in the C library in the first place. This is fairly simple to do; just change the search to gracefully unwind when a time limit is encountered.

----

Current match score, Symbolic vs tscp: 299-42-40 (+285 elo)

I'll post the games after the match completes.

[hgm]

Adding support for SAN and FEN I/O to tscp would better support xboard v2,

No, why do you say that? Adding support for SAN is a step in the wrong direction; SAN should be avoided like the plague in v1 and v2 alike, and allowing it in the first place is in fact the worst defect of CECP.

FEN usage through the setboard command has no practical advantage over relying on the 'edit' command; v2 supports both.

but the primary motivation is to make the program more friendly for play vs humans via a console interface. For example, tscp currently has no easy way to set up a position, and this would be fixed with FEN input capability.

That is a goal that has nothing to do with v1 vs v2, or in fact with XBoard protocol at all. IIRC using CECP needs a special command-line option in TSCP. It has a separate command parser for playing in console mode.

If there is anything that could be called a waste of time then having a Chess engine play in 'user-friendly console mode' seems to be a good candidate for heading the list. (Apart from being an oxymoron.)

SAN would be useful for both human move entry and also for the display of a predicted variation.

This also has nothing to do with the CECP version, as both v1 and v2 define PV output as free-format text. When running in a GUI it should be left to the GUI to present the PV in the format preferred by the user, as XBoard does.

Two more edits which would significantly speed up the program without changing move selection logic:

1) Track the location of each king for use when testing in-check status; at present the entire board is scanned to locate a king.

2) Add incremental hash signature updating; at present the entire board is scanned after each move.

These are attempts at speeding up the program, which would affect move choice by allowing it to search deeper. Similar attempts by equipping TSCP with a full-fledged piece list have already been dismissed by Tom Kerrigan.

[sje]

As for human friendliness, how many chess magazines, chess books, and chess web sites use coordinate notation? Coordinate notation may have been needed in the days of machines limited to 8 KiB memory, but today it's used only by a small and likely dwindling number of coders. Even the old English Descriptive Notation is better than coordinate notation, as is evidenced by the use of EDN in programs from the 1960s and 1970s -- and writing a proper implementation of EDN is harder than doing one for for SAN.

I said that my tscp edits, current and proposed, would not cause a change in the move selection logic. I did not say that they wouldn't change move choice; move choice can be changed by something as simple as running on a faster or slower machine. When used with a fixed depth limit, move choice will be unchanged because the logic is unchanged.

Piece lists may very well, almost certainly, change move selection logic causing different move picks for the same search node count.

Anyway, since it's Tom's program, I'll let him decide what's acceptable and I'll postpone any more work on tscp if/until he grants permission.

----

Current match score: 315-45-44 (+281 elo)

[hgm]

As for human friendliness, how many chess magazines, chess books, and chess web sites use coordinate notation? Coordinate notation may have been needed in the days of machines limited to 8 KiB memory, but today it's used only by a small and likely dwindling number of coders. Even the old English Descriptive Notation is better than coordinate notation, as is evidenced by the use of EDN in programs from the 1960s and 1970s -- and writing a proper implementation of EDN is harder than doing one for for SAN.

The point is that an engine-GUI communication protocol is not intended for human consumption, and should strive for the goal of fast and easy parsing and generation, and unambiguity even in the absence of rule knowledge.

I said that my tscp edits, current and proposed, would not cause a change in the move selection logic. I did not say that they wouldn't change move choice; move choice can be changed by something as simple as running on a faster or slower machine. When used with a fixed depth limit, move choice will be unchanged because the logic is unchanged.

Piece lists may very well, almost certainly, change move selection logic causing different move picks for the same search node count.

Anyway, since it's Tom's program, I'll let him decide what's acceptable and I'll postpone any more work on tscp if/until he grants permission.

Sure. I just point out that in the past Tom has always refused such requests. Not because he is worried that move choice or selection logic gets changed, but because it complicates the code. His goal is to keep the code simple, even when the price for this a significant slowdown. I don't think he cares anything about how it actually plays, as long as it plays legally.

[Dann Corbit]

IMO, fixing TSCP is really barking up the wrong tree.

It has lots of global variables and is really not a terribly good place for a beginner to start.

This thing, for instance:
http://www.3dkingdoms.com/chess/sam/samchess.html
is a lot better.

Or maybe this one:
http://kirr.homeunix.org/chess/engines/ ... ess%2026g/

TSCP?
Just say no.

[sje]

IMO, fixing TSCP is really barking up the wrong tree.

It has lots of global variables and is really not a terribly good place for a beginner to start.

Perhaps; but tscp is useful in part because of being widely distributed over nearly two decades.

----

Current match score: 525-76-71 (+281 elo)

[Dann Corbit]

IMO, fixing TSCP is really barking up the wrong tree.

It has lots of global variables and is really not a terribly good place for a beginner to start.

Perhaps; but tscp is useful in part because of being widely distributed over nearly two decades.

----

Current match score: 525-76-71 (+281 elo)

Is that a solution or is that a problem?

If a beginner wants to learn from a simple program there are much better examples like Sungorus (array based) or Olithink (bitboard).

IMO-YMMV

[velmarin]

IMO, fixing TSCP is really barking up the wrong tree.

It has lots of global variables and is really not a terribly good place for a beginner to start.

Perhaps; but tscp is useful in part because of being widely distributed over nearly two decades.

----

Current match score: 525-76-71 (+281 elo)

Is that a solution or is that a problem?

If a beginner wants to learn from a simple program there are much better examples like Sungorus (array based) or Olithink (bitboard).

IMO-YMMV

Vice wiht "youtube documentation", Winglet with "100 step a step", ect, ect.

[PK]

TSCP taught me several valuable lessons, and is immensely useful as an *unmodified* benchmark for the beginning programmers.

Creating a *modfiable* learning engine is a different task altogether.

As I am in the process of rewriting Rodent, having thrown away two prototypes, I am tempted to start by creating "Sungorus++", fixing four bugs of the original engine that I am aware of, renaming too cryptic variables, adding LMR, basic king safety and comments.

However, I suppose that for this project to be really useful for the beginners, I would need a more experienced programmers' guidance.