iPlayChess - A TalkChess Community Engine

[mvanthoor]

Don't think so. It should be "-CHECKMATE + ply" which is of course the same as "-(CHECKMATE - ply)".

Yes, of course. You're right. I overlooked the significance of the brackets. In my code, I never invert a calculation like that. In this particular context for checkmate, I've also never seen this notation (all code I've seen seems to use -CHECKMATE + ply, without the brakcets), so when I saw the minus ply, it looked like a mistake.

[Henk]

Code already looking ugly so it must be good code.
Only ugly code runs fast.

By the way I thought it was normal using Pascal case or camel case instead of underscores.

I remember last time I used underscores was about twenty years ago.

[maksimKorzh]

Hi Mike

This is a lovely idea but unfortunately it often happens that something interesting to you always remains interesting to you only. I'll be happy if this is not the case. Well at least this is what happens to me - if I share something specific to my interest it gets criticized without revealing the underlying circumstances.

P.S. Just curious what happened to your previous engine? Did you release or drop it?

[mvanthoor]

Code already looking ugly so it must be good code.
Only ugly code runs fast.

Only ugly code runs fast; what kind of an assumption is that?

By the way I thought it was normal using Pascal case or camel case instead of underscores. I remember last time I used underscores was about twenty years ago.

The old is new again. Newer programming languages (including Rust, and Python) have a preference for underscores.

WhenUsingLongFunctionNames(), code quickly becomes less readable. underscores_have_no_such_problem(), so your function and variable names can be much more descriptive.

[mvanthoor]

This is a lovely idea but unfortunately it often happens that something interesting to you always remains interesting to you only. I'll be happy if this is not the case. Well at least this is what happens to me - if I share something specific to my interest it gets criticized without revealing the underlying circumstances.

The reason why this effort probably isn't going to take off isn't because of disinterest, but because it's very hard to build software with multiple people, if you don't split it into modules first, create and document interfaces/api's/public functions for those modules, and then assign a module to a developer. Software engineering as a discipline not only aims at writing better software, but particularly aims at writing software with multiple people working in the same codebase.

So if this is going to succeed, we'd need:

- a main object to contain other parts of the engine (in its own thread)
- board representation
- move generator
- search function (in its own thread)
- evaluation function
- uci protocol (in its own thread)
- modules don't communicate with one-another directly; they go through the main thread. This avoids one module depending on another.

each with either their own interface, or well-documented public functions. All of that should be in a Github or Gitlab repository, so people can pull the code, and work (on a part of) a module.

I think that posting code back and forth in the forums is not going to work well in the long run.

[Henk]

Only ugly code runs fast; what kind of an assumption is that?

How often does it happen that when you replace ugly code with dirty tricks being difficult to understand and replace it with clean code but losing at least 50 elo.

By the way bitboard code is ugly code.

Clean code does not make it. Too slow. Other example: Linq.
ImmutableList etc. Also too slow.

[abulmo2]

1. C - cpp as a better C

Do you mean you are going to abuse the C preprocessor?
Whatever, there is no betterC for cpp:

Code: Select all

$ cpp -betterC hello.c
$ cpp: error: unrecognized command-line option '-betterC'

Use a D compiler instead:
$ ldc2 -betterC hello.d
$ hello

Code: Select all

Hello betterC

If you want a better C ,use a better language

As it seems that 90% of authors prefer UCI protocol I guess I'll have to learn UCI, ouch. Maybe someone can contrib some UCI code to Get_Command()?

Code: Select all

s32 main() {
  Move move;

  Initialize();

  while (play) {
    Get_Command();
    if (play == PLAY) move = I_Play_Chess(thread[0]);
    if (play == MOVE) Game(move);
  }

  return 0;
}

This is not UCI compliant. UCI does not send move, but a position (with eventually a serie of moves) before asking to think with the go command.
I prefer int main(void) to s32 main() as a more pedantically conforming definition of main, I also hate global variable like play, thread[0], etc. but I guess it is your style. So a more UCI like loop could be in your style could be:

Code: Select all

s32 main() {
  Move move;

  Initialize();

  while (play) {
    Get_Command();
    if (play == UCI) UCI_Info();
    if (play == GO) I_Play_Chess(thread[0]);
    if (play == POS) Set_Position(thread[0]);
    // etc.
  }

In my style a C UCI loop will looks more like that:

Code: Select all

/* Main loop */
int main(void)
{
	char *line = NULL, *param = NULL;
	Uci uci[1];

	globals_init();

	uci_init(uci);

	// loop forever
	for (;;) {
		line = event_wait(uci->event);

		// skip spaces
		param = parse_next(line);

		// uci
		if (parse_command(&param, "uci")) {
			uci_send(uci, "id name %s %s", NAME, VERSION);
			uci_send(uci, "id author %s", AUTHOR);
			uci_send(uci, "option name Hash type spin min %d default %d max %d", HASHSIZE_MIN, hash_size, HASHSIZE_MAX);
			uci_send(uci, "option name Ponder type check default false");
			uci_send(uci, "uciok");

		// ucinewgame
		if (parse_command(&param, "ucinewgame")) {
			uci_new_game(uci);

		// debug mode
		} else if (parse_command(&param,"debug")) {
			uci_debug(uci);

		// isready
		} else if (parse_command(&param,"isready")) {
			uci_send(uci, "readyok");

		// setoption
		} else if (parse_command(&param,"setoption")) {
			uci_set_option(uci, &param);
									 
		// position
		} else if (parse_command(&param,"position")) {
			uci_set_position(uci, &param);

		// go think!
		} else if (parse_command(&param,"go")) {
			uci_go(uci, &param);

		// stop
		} else if (parse_command(&param,"stop")) {
			uci_stop(uci);

		// ponderhit
		} else if (parse_command(&param,"ponderhit")) {
			uci_ponderhit(uci);

		// quit
		} else if (parse_command(&param,"quit")) {
			break;

		}
			
		free(line);
	}

	uci_free(uci);

	return 0;
}

[Mike Sherwin]

Hi Mike

This is a lovely idea but unfortunately it often happens that something interesting to you always remains interesting to you only. I'll be happy if this is not the case. Well at least this is what happens to me - if I share something specific to my interest it gets criticized without revealing the underlying circumstances.

P.S. Just curious what happened to your previous engine? Did you release or drop it?

Bricabrac has a bizarre bug that I have not been able to squish. When a side is losing that side's king heads for a1 and when it gets there it commits suicide by capturing itself. Other than that Bric is fantastically fast and some of my best work yet. However, it can be made better. Therefore this is a rewrite, i guess. Also when I first wrote RomiChess it was to be just a prototype. I always planned on rewriting RomiChess to be multithreaded and rename it Andromeda. So this to me will be the new RomiChess. Romi or Rommie was the AI avatar, played by Lexa Doig, of the starship Andromeda Ascendant. Before I could do that my mom came down with Alzheimer's and I had to take care of her. In the process I got so worn down that I became very ill and had to put her in a nursing home. That started in early 2008 and in March of 2012 my mom died. I have been trying to fight my way back ever since. This is the closest I have come to be able to finish what I started all those years ago. I just hope that I have enough time left.

[mvanthoor]

Bricabrac has a bizarre bug that I have not been able to squish. When a side is losing that side's king heads for a1 and when it gets there it commits suicide by capturing itself.

You could try to debug that by logging each evaluation and king move pair to a file. Then you may be able to see a pattern.

What I could think of is something like an "off by one": if you use a 0-63 array, and you happen to subtract 1 from the square where the king is now, if the evaluation is negative (but not subtract 1 if the square is already 0), then your king would move to the left all the time until it reaches A1, and then the next move would be a1a1.

My best move starts out initialized at 0, so if the iterative deepening thread ends up without a move (which should never happen, because it completes at least one iteration), it would send "000000" to the main thread, which would parse this as a1 to a1 promotion to K (move a1a1k).

[Mike Sherwin]

This is a lovely idea but unfortunately it often happens that something interesting to you always remains interesting to you only. I'll be happy if this is not the case. Well at least this is what happens to me - if I share something specific to my interest it gets criticized without revealing the underlying circumstances.

The reason why this effort probably isn't going to take off isn't because of disinterest, but because it's very hard to build software with multiple people, if you don't split it into modules first, create and document interfaces/api's/public functions for those modules, and then assign a module to a developer. Software engineering as a discipline not only aims at writing better software, but particularly aims at writing software with multiple people working in the same codebase.

So if this is going to succeed, we'd need:

- a main object to contain other parts of the engine (in its own thread)
- board representation
- move generator
- search function (in its own thread)
- evaluation function
- uci protocol (in its own thread)
- modules don't communicate with one-another directly; they go through the main thread. This avoids one module depending on another.

each with either their own interface, or well-documented public functions. All of that should be in a Github or Gitlab repository, so people can pull the code, and work (on a part of) a module.

I think that posting code back and forth in the forums is not going to work well in the long run.

Thanks for taking an interest. Thanks for looking at the code. It can be separated into separate source files and put in a repository. Is it a viable project for TalkChess, maybe not. But is it worth trying? I give that a yes.