NADYA2.0 engine progress

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: NADYA2.0 engine progress

Post by BlueStar »

Tony P. wrote: Thu Jul 16, 2020 6:42 am The test-time speed is what's stopping me and probably many others from considering Prolog as a language to write or fork a complete engine in. Out of curiosity, what other languages did you consider, and why did you reject them?
I have to stipulate, the Prolog compiler I am using is crazy fast, and I'm not yet worried about speed issues. Current NPS counts are solely on me focusing on accuracy and diagnostic checks.

As far as considering other languages, I've been writing commercial software for 30+ years in any number of languages. Then COVID-19 happened, and the world went crazy, so I decided to go back to a happy place when I had my first 8086 computer, and remembered Turbo Prolog. Then I asked my daughter Nadya, speed or elegance for a chess program--even though I already knew her answer. I had already decided it was either going to be C++/Assembly or Prolog/C based on her answer.

Here is another code sample of my move generator for example:

Code: Select all

predicates
    promote:(move) -> move nondeterm.

clauses
    promote(M) = Move :-
        Move = if M:is_promotion then M:for_each_promotion() else M end if.

clauses
    for_each_bb_move() = Move :-
        BB = move_bb(for_each_piece(to_play)),
        Move = move::new(This, BB:piece, BB:for_each_pos()).

clauses
    for_each_move() = Board :-
        M = promote(for_each_bb_move()),
        Board = make_move(M).
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: NADYA2.0 engine progress

Post by mvanthoor »

BlueStar wrote: Fri Jun 19, 2020 11:37 pm As I mentioned, I've been eyeing your progress on TalkChess, and enjoy seeing the progress you are making with Rustic. Can't wait to play you eventually. If even if Rustic ends up being 20 times faster. :)

Cheers,
C Hoibakk.
I'd love to. I hope you're still making progress?

In my case, Rustic has been on hold for some time. I'm not stuck writing the engine, but I have a vision problem. My eye sight is 35% at the best of time, in only my right eye. (My left eye only has 7% vision since birth.) I'm awaiting a cataract surgery for my right eye at the moment (even though I'm not even CLOSE to an age you'd expect a cataract surgery to be necessary). My vision is exceedingly poor at this time. I can BARELY get through an 8 hour working day and I'm basically wasted in the evening.

The one thing I'm now doing (after some rest after I get home), is building my own custom PicoChess image. ( https://groups.google.com/g/picochess ) It requires only to tinker a bit on the Linux comamnd line, and I know exactly what to do. I can break this up in tiny parts until the image is done... it's only taking me two weeks now instead of half a day. (I intend it to be the basis for my own personal Rustic Chess Computer, in combination with a DGT board.)

This image will be free/open source of course, as it's based on all open source stuff. The only thing you'll need is a Raspberry Pi (any model, except for maybe the A types... I've not yet seen anyone install PicoChess on that one), a DGT chess board and pieces (USB or Bluetooth), and the DGT3000 clock, and you'll have your own chess computer. The DGT board and pieces are not cheap, but great to play on. (And they did introduce a cheaper, somewhat smaller, plastic version; not as DeLuxe as the fully wooden boards and pieces, but it works fine.)

The surgery will be end of next month, and then I'll need about a month of recovery time including having new prescription glasses measured up and waiting for those. If all is well, I'd be back to normal in the beginning of October this year.

I assume Rustic's development will be on halt until at least that time.

(You, and others, may have noticed that I'm not really posting in this forum much in the last two months; and now you know why.)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: NADYA2.0 engine progress

Post by BlueStar »

(You, and others, may have noticed that I'm not really posting in this forum much in the last two months; and now you know why.)
Oh wow. I sure hope things improve. Yes, making steady progress. Currently working on: Improving speed in the move generator, adding observation of post-perft chess rules (50 move rule, 3 fold repetition, etc), and integrating the old NADYA1.0 simple board evaluator. I added a non-gui mode for WinBoard, and verified that WinBoard recognizes it and that NADYA2.0 recognizes the first "xboard" command.

I hope things go well for you!
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: NADYA2.0 engine progress

Post by mvanthoor »

BlueStar wrote: Thu Jul 30, 2020 12:42 am
(You, and others, may have noticed that I'm not really posting in this forum much in the last two months; and now you know why.)
Oh wow. I sure hope things improve. Yes, making steady progress. Currently working on: Improving speed in the move generator, adding observation of post-perft chess rules (50 move rule, 3 fold repetition, etc), and integrating the old NADYA1.0 simple board evaluator. I added a non-gui mode for WinBoard, and verified that WinBoard recognizes it and that NADYA2.0 recognizes the first "xboard" command.

I hope things go well for you!
Thanks for the wishes.

Is there a reason to start with xboard support first? Even though eventually I'll probably support both, I feel that nowadays there are many more UCI GUI's to choose from than xboard GUI's (although some, like Arena, support both).
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: NADYA2.0 engine progress

Post by BlueStar »

Is there a reason to start with xboard support first? Even though eventually I'll probably support both, I feel that nowadays there are many more UCI GUI's to choose from than xboard GUI's (although some, like Arena, support both).
When I investigated, it seemed the XBoard interface was closer to my engine command-line interface. Also, my cursory research made me believe UCI takes control over state, and while that would be tempting to rely on, I want to have an engine that won't have to rely on those things (at least for now).
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: NADYA2.0 engine progress

Post by mvanthoor »

BlueStar wrote: Mon Aug 17, 2020 5:48 am
Is there a reason to start with xboard support first? Even though eventually I'll probably support both, I feel that nowadays there are many more UCI GUI's to choose from than xboard GUI's (although some, like Arena, support both).
When I investigated, it seemed the XBoard interface was closer to my engine command-line interface. Also, my cursory research made me believe UCI takes control over state, and while that would be tempting to rely on, I want to have an engine that won't have to rely on those things (at least for now).
Yes. UCI makes the GUI take control over everything but search and evaluation. (You can, however, set opening books and endgame tablebases in an engine if it supports it, and disable both in the GUI; at least in Chessbase GUI's.)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: NADYA2.0 engine progress

Post by BlueStar »

NADYA2.0 - now consistently defeats me (I'm not a great chess player). It is multi-threaded, uses PV and TT hash tables, killer moves, heuristics, move sorter... XBoard interface is coming next. I'm at the point where I need it to play it against other engines to know if the changes I am making are improving, or making it worse, because I can no longer tell on my own w/o plugging positions into another engine for comparison evaluation.

I believe I am still on track to shelve 2.0 in November, and start 3.0 with all the design/architecture changes I've identified building V2.
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: NADYA2.0 engine progress

Post by mvanthoor »

BlueStar wrote: Wed Sep 16, 2020 2:02 am NADYA2.0 - now consistently defeats me (I'm not a great chess player). It is multi-threaded, uses PV and TT hash tables, killer moves, heuristics, move sorter... XBoard interface is coming next. I'm at the point where I need it to play it against other engines to know if the changes I am making are improving, or making it worse, because I can no longer tell on my own w/o plugging positions into another engine for comparison evaluation.

I believe I am still on track to shelve 2.0 in November, and start 3.0 with all the design/architecture changes I've identified building V2.
I'm back :) (https://www.youtube.com/watch?v=VBTRp80Q64U)

Good to hear that you are still making progress. I hope that with "shelving" Nadya 2.0 you mean that you're going to call this version finished, and then continue development as version 3.0? I certainly hope you're not going to start over? That'll take you weeks or months to get to the point where you are now. The only good reason (in my opinion) would be to use a faster programming language, or if your current architecture and code is really horrible and unmaintainable. (As you said that you've been writing software for over 30 years, I doubt that you're writing horrible code. At least, I hope so.)

You're now much further along than I am, but I did pick up Rustic's development again, even if it's a bit slow, as I still can't use a computer for hours on end. That'll come in a few weeks. Progress topic:

http://talkchess.com/forum3/viewtopic.php?f=7&t=75129

The next part I'm going to write is the search, put in PSQT's, and then write the UCI interface. I'm curious to see how this bare bones Rustic would perform against Nadya 2.0. Maybe Rustic's brute force calculation power will be enough to offset Nadya 2.0's extra functionality... but I doubt it. A little bit of knowledge often goes a long way in chess. (Look at TSCP: if you're a new engine, you better either see far into the future or you know what a passed pawn is, or you're going to be smoked.)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
eventhorizon02
Posts: 1
Joined: Fri Sep 18, 2020 3:59 pm
Full name: Benny Abramovici

Re: NADYA2.0 engine progress

Post by eventhorizon02 »

Hi,
I have written a C++ chess engine in the past as a learning experiment, the board was represented as a one dimensional array.
I am now attempting to write a very simple chess engine in Prolog for a class I'm taking in my old age.
It's going to be a super simple one and I'm still trying to figure out whats the best way to represent the board and the pieces.
There are no arrays in prolog, they can be somewhat simulated with lists.
How are you presenting your board, can you give some advise?
cheers
BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: NADYA2.0 engine progress

Post by BlueStar »

eventhorizon02 wrote: Mon Sep 21, 2020 6:17 pm Hi,
I have written a C++ chess engine in the past as a learning experiment, the board was represented as a one dimensional array.
I am now attempting to write a very simple chess engine in Prolog for a class I'm taking in my old age.
It's going to be a super simple one and I'm still trying to figure out whats the best way to represent the board and the pieces.
There are no arrays in prolog, they can be somewhat simulated with lists.
How are you presenting your board, can you give some advise?
cheers
Hi, Just saw this. Sorry I've been away for a while. I use a modern version of Prolog "Visual Prolog" that you can download for education for free. Modern Prolog has come a long way since the Edenburge prolog your class might have you using. Your can write your own "array" classes in modern prolog, or use one from an existing library. Here are some of the constants and variables for my "Board" class. I use a customizable board size (in this example 8x8).

Code: Select all

constants
    allow_no_piece : boolean = true.
    validate_piece : boolean = false.
    board_size : positive = 64.
    row_count : positive = 8.
    col_count : positive = 8.
Some class variables from my board.pro:

Code: Select all

facts
    b_state : state := erroneous.
    b : arrayM_inline{c_piece} := arrayM_inline{c_piece}::new(board_size). % Array here!
    my_move : move := erroneous.
    score_ : c_score := erroneous.

    k_pos_w : c_pos := find_kings_(white) [constant].
    k_pos_b : c_pos := find_kings_(black) [constant].

    pos_bits_w : c_bb := get_pos_bits_w_() [constant].
    pos_bits_b : c_bb := get_pos_bits_b_() [constant].

    tlw : c_bb := 0.
    tlb : c_bb := 0.

    board_index : arrayM_inline{c_pos} := arrayM_inline{c_pos}::new(board_size). % Array here! 
My Prolog engine uses lists everywhere, but for the board, I use a "modifiable" array from the library the Visual Prolog compiler provides. The code above where you see the comment % Array here! for "arrayM_inline" is the array class. The "M" stands for "modifiable", which as you know in Prolog you want to be careful with.

Now when I check the validity of moves on the board size, since we know the exact "distance" pieces can move when they make a "single" move (i.e. a single move for a bishop on my board for distance will be +-1 in a vertical position, and then +- 1 in horizontal position for a total of two. If the piece moves beyond the "distance" of 2 on an 8x8 board, we know that move is off the board. You have to take special consideration for the pawn (first possible move/captures), and the king (castling). And for example for an 8x8 size board this code, I use this code to calculate the distance.

Code: Select all

clauses
    % i,i,o
    distance(X, Y, D) :-
        R1 = X div 8, C1 = X mod 8,
        R2 = Y div 8, C2 = Y mod 8,
        D = math::abs(R1-R2) + math::abs(C1-C2).
If the distance, does not equal the "fact" assertion of the move distance for a particular piece then it is invalid. The predicate that would call this is a "determ" predicate, so if the move is invalid, it is rejected.

Sorry I only just saw this post, I hope even though I suspect your class project might be restricted to Edenburge Prolog, that the above will help a tiny bit. If your are restricted to Edenburge, PM me and I can give you advice on using a "string" board for simplicity (which is precisely what my NADYA1.0 experiment used). Most Prolog implementations have very good string manipulation packages.

In case this is not too late, I'll check my PM's here on TalkChess more often to help you out if you still need any advice.

Cheers,
CHoibakk