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.Joost Buijs wrote: ↑Thu Mar 25, 2021 9:56 am Don't think so. It should be "-CHECKMATE + ply" which is of course the same as "-(CHECKMATE - ply)".
iPlayChess - A TalkChess Community Engine
Moderators: hgm, Rebel, chrisw
-
- Posts: 1784
- Joined: Wed Jul 03, 2019 4:42 pm
- Location: Netherlands
- Full name: Marcel Vanthoor
Re: iPlayChess - A TalkChess Community Engine
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: iPlayChess - A TalkChess Community Engine
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.
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.
-
- Posts: 771
- Joined: Sat Sep 08, 2018 5:37 pm
- Location: Ukraine
- Full name: Maksim Korzh
Re: iPlayChess - A TalkChess Community Engine
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?
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?
Didactic chess engines:
https://www.chessprogramming.org/Maksim_Korzh
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
https://www.chessprogramming.org/Maksim_Korzh
Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ
-
- Posts: 1784
- Joined: Wed Jul 03, 2019 4:42 pm
- Location: Netherlands
- Full name: Marcel Vanthoor
Re: iPlayChess - A TalkChess Community Engine
Only ugly code runs fast; what kind of an assumption is that?
The old is new again. Newer programming languages (including Rust, and Python) have a preference for underscores.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.
WhenUsingLongFunctionNames(), code quickly becomes less readable. underscores_have_no_such_problem(), so your function and variable names can be much more descriptive.
-
- Posts: 1784
- Joined: Wed Jul 03, 2019 4:42 pm
- Location: Netherlands
- Full name: Marcel Vanthoor
Re: iPlayChess - A TalkChess Community Engine
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.maksimKorzh wrote: ↑Thu Mar 25, 2021 11:03 am 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.
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.
Last edited by mvanthoor on Thu Mar 25, 2021 12:15 pm, edited 1 time in total.
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: iPlayChess - A TalkChess Community Engine
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.
-
- Posts: 433
- Joined: Fri Dec 16, 2016 11:04 am
- Location: France
- Full name: Richard Delorme
Re: iPlayChess - A TalkChess Community Engine
Do you mean you are going to abuse the C preprocessor?1. C - cpp as a better C
Whatever, there is no betterC for cpp:
Code: Select all
$ cpp -betterC hello.c
$ cpp: error: unrecognized command-line option '-betterC'
$ ldc2 -betterC hello.d
$ hello
Code: Select all
Hello betterC
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()?
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.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; }
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.
}
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(¶m, "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(¶m, "ucinewgame")) {
uci_new_game(uci);
// debug mode
} else if (parse_command(¶m,"debug")) {
uci_debug(uci);
// isready
} else if (parse_command(¶m,"isready")) {
uci_send(uci, "readyok");
// setoption
} else if (parse_command(¶m,"setoption")) {
uci_set_option(uci, ¶m);
// position
} else if (parse_command(¶m,"position")) {
uci_set_position(uci, ¶m);
// go think!
} else if (parse_command(¶m,"go")) {
uci_go(uci, ¶m);
// stop
} else if (parse_command(¶m,"stop")) {
uci_stop(uci);
// ponderhit
} else if (parse_command(¶m,"ponderhit")) {
uci_ponderhit(uci);
// quit
} else if (parse_command(¶m,"quit")) {
break;
}
free(line);
}
uci_free(uci);
return 0;
}
Richard Delorme
-
- Posts: 866
- Joined: Fri Aug 21, 2020 1:25 am
- Location: Planet Earth, Sol system
- Full name: Michael J Sherwin
Re: iPlayChess - A TalkChess Community Engine
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.maksimKorzh wrote: ↑Thu Mar 25, 2021 11:03 am 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?
-
- Posts: 1784
- Joined: Wed Jul 03, 2019 4:42 pm
- Location: Netherlands
- Full name: Marcel Vanthoor
Re: iPlayChess - A TalkChess Community Engine
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.Mike Sherwin wrote: ↑Thu Mar 25, 2021 5:08 pm 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.
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).
-
- Posts: 866
- Joined: Fri Aug 21, 2020 1:25 am
- Location: Planet Earth, Sol system
- Full name: Michael J Sherwin
Re: iPlayChess - A TalkChess Community Engine
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.mvanthoor wrote: ↑Thu Mar 25, 2021 12:14 pmThe 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.maksimKorzh wrote: ↑Thu Mar 25, 2021 11:03 am 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.
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.