Editing tscp

[sje]

Perhaps the search should be flattened into a non-recursive routine. This would make the source more useful for those who've seen only the recursive technique. The FSM would need only about nine or ten states.

[Dann Corbit]

There are two simple speed enhancements which can be made by adding only a small amount of code:

1) Incremental updating of king positions. At present, the code must scan the entire board each time it test for a king-in-check condition.

2) Incremental updating of the signature hash. At present, the code must scan the entire board each time it makes a move.

Many other changes could be made to improve the speed without changing move selection or node counts. But which changes are simple enough for the program to remain simple overall?

#1 is one of the two things I added.
You only have to update the king position on makemove and unmakemove.
It's trivial.

The other thing I added was an eval hash.
Also trivial.

Got to 9 plies in 33 seconds for the root position.

[bob]

Not so simple enhancements

The first of these would be to get rid of the setjmp()/longjmp() calls by changing the search to gracefully unwind when the time limit strikes. This would not change move selection or node counts, but it would provide a better tutorial example of structured programming.

The second of these would be to install FEN I/O capability, as currently there is no easy way to set up an arbitrary position. This could be extended to allow the setboard directive when running under xboard.

The third not so simple change would be to support SAN I/O. This takes a little more work, but I think it's worth the effort as coordinate notation is something best left to the 1970s.

A fourth idea would be to support PGN I/O. The output side of this is fairly easy once SAN is supported, but the parsing side is more complex. Perhaps allowing only the most simply formatted PGN games to be read would be sufficient.

Do you have any idea how many people have refused to implement SAN, even today? I even added an option to my testing referee so that it will take SAN as it always did, but if requested, convert to algebraic before relaying. MANY programs (MOST programs) can't deal with SAN, for reasons I will never understand...

[hgm]

SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...

[mvk]

SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...

I was told that not long ago one of the "well-established programs" entering the CSVN tournament produced ambiguous and therefore invalid SAN in its output for the similarity test. (A test which explicitly and generously accepts UCI move notation as alternative notation for the operand of the "bm" opcode, BTW).

[bob]

SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...

Why? Why is there a need to have TWO output formats? Correct san is easy to interpret...

However, this is not JUST a protocol issue. I am talking about move output and input, such as what is displayed in PVs, when moves are played, etc...

Some (many) programs can't display moves in SAN as I play them, they display coordinate or worse..

[bob]

SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...

I was told that not long ago one of the "well-established programs" entering the CSVN tournament produced ambiguous and therefore invalid SAN in its output for the similarity test. (A test which explicitly and generously accepts UCI move notation as alternative notation for the operand of the "bm" opcode, BTW).

I was not talking about bad SAN, ambiguous SAN, incomplete SAN (promotion piece, etc). I have seen programs output bogus coordinate output as well. Doesn't mean that because someone can't do it right then it should not be done period. We would have NO move format if that were true.

[Dann Corbit]

SAN is easier for a human to read. Well, at least for me it is.
I imagine that some people might read coordinate notation just as well.

[michiguel]

SAN is utterly unsuitable as move format for in a comminication protocol, and should be outlawed. The fact that you are allowed to send moves as SAN is the biggest mistake of XBoard protocol. This is one thing where UCI got it right...

+1000

Including SAN in the xboard protocol was a blunder of gigantic proportions. It bloated software for no reason whatsoever. It was a magnet for bugs and GUI tantrums. Some GUI refused to correctly managed the "+" (check), since it required extra code that could potential slow down the process. This made some engines hang, since technically they were sending "illegal" moves (a check without a "+"). It is good for human communication, but for computers it is not.

Even though Gaviota's SAN input/output is correct, when I set Gaviota to use "e2e4" format by default, many of the headaches went away. The other option would have been to accept "non-standard" SAN and make the code even more bloated.

Miguel

[michiguel]

SAN is easier for a human to read. Well, at least for me it is.
I imagine that some people might read coordinate notation just as well.

Yes, I agree, but the engine could accept it independently from the engine-engine protocol.

Miguel