NADYA2.0 supports castling, en-passant, 50 move limit, etc, so should be a fully legal chess engine when working (notice I don't use the word "completed" lol).
Some confusing and interesting facts about PROLOG that I believe gives me a reliability advantage and actually helps to greatly eliminate bugs and debugging time. In Prolog, a variable is considered either "bound" or "unbound". While there are ways in some implementations to get around this, once a variable is "bound" (i.e. assigned a value), it cannot be changed (i.e. no MAKE/UNMAKE move). Cant unmake something that is read-only. To help eliminate bugs and embrace the AI concepts(I use that extremely loosely, as I think that term is mostly misused) and language constructs like backtracking, etc. My compiler has the incredibly cool feature to also have the ability to have "delayed assignment to a constant" (i.e. calculated only when it is first referenced). I try to use this to my advantage when I can. Even in my prolog classes (which can have modifiable variables), I choose to only use them as constants once assigned. The one exception so far, is in my PERFT function (of which I'll post to this thread) with my "counter" class that counts moves, checks, checkmates, capture counts, etc.
I am just starting my PERFT testing, but I'm not posting any NPS counts counts after reading the earlier PERFT topic and realizing just how much slower my engine is (HINT: I have not yet reached even 1-million NPS). Fortunately, when I started NADYA2.0, I asked my daughter, "since it shares your namesake, do you want it to be based on speed or elegance?", she didn't hesitate and said elegance, so as I mention on the title screen, "She said elegance, so that will forever be it's goal." So I'm using that as my excuse for slower performance
. HOWEVER, I'm not even going to attempt any but the simplest performance increases until I can pass all of my perft testing perfectly. Even the tiniest of changes in this critical code can introduce frustrating problems.I have had to write a single external "C" DLL unfortunately, as my PROLOG compiler throws exceptions on all math overflows (which doesn't allow for calculating things like De Bruijn sequences, or magic bit-board keys). However, rather than write the whole De Bruijn code in "C", I only write the required functions (keeping the De Bruijn sequence in Prolog) as in:
UINT64 APIENTRY Mult_no_overflow(UINT64 A, UINT64 B)
{
return A * B;
}
I have also created a handful of conversion routines in my DLL, as type conversion (especially between different types, or sizes), it is pure torture, and found myself spending as much time trying to learn how to convert various types as writing the actual code. for instance converting a 64-bit integer to a 32-bit integer, or converting between a string/number. (This is probably my ignorance of the compiler I am using, so I'm not trying to fault the compiler). So most all my code is from scratch--and with the additional overhead of a massive PROLOG learning curve. It has now taken me longer to write just my move generator for NADYA2.0 than it took to write all of NADYA1.0 (which I now consider an ignorant learning excercise--that taught me just how exacting (i.e. PERFECT) a chess engine has to be). So I started from scratch (re-using my NADYA1.0 text GUI interface), and am building all of NADYA2.0 on top of a custom diagnostic framework (I'm SO glad I did!). Another reason it is slow--and it is hard to turn off my diagnostic code with the prolog compiler and my design implementation, so I might have to spend some time to "disconnect" my diagnostic framework somewhat, so I can compile with or w/o it, but again not worried about that until the the move generator passes perft testing.
Once I have a working engine, I will be enlisting additional help to start the forever project of improving it (especially in the area of board evaluation).
I will attach some sample source, and a few screen shots to this thread to give you a sample preview. However, if your like me when I first started prolog again, it might not make a lot of sense--but maybe give an example of me trying write for elegance. However, for you all, I believe the actual logic itself will make perfect sense. Sometimes, I feel like I'm writing in "steam-punk" (my description), because I'll have some beautiful pure prolog logic, and then a whole swath of bit-wise math that follows. The mixing of high level/low-level makes it look to me like what I call "steam-punk" code.
I will post an update and examples now again, and I know I will have a ton of questions. I don't anticipate a first playable version of NADYA2.0 for at least a few months at an absolute minimum however.
Cheers
C. Hoibakk.
since as you say we are close in development progress!
There are, however, important chess tasks that this approach would excel at, such as the verification of either side's ability to secure at least a draw, which would increase the accuracy of evals in training sets; and the procedural generation of positions with forced wins, draws or tactics giving an almost decisive advantage (e.g. over +2.0) at any game stage, allowing both to create a puzzle generator with more diverse and personalized output than the existing puzzle DBs, and to speed up the reinforcement learning of a full chess engine.
with