Is cloning a hobby?

[OliverBr]

I was very hesitant in posting Drofa 1.0.0 here, because even though it had over 300 elo more than Shallow Blue (engine that i forked), even with
some of the files rewritten completely, i somehow felt that its not entirely different engine.

Thank you for your engine!
I cloned the repo (https://github.com/justNo4b/Drofa) and it works very well under Linux with gcc! I will late make some tourneys with it.

Edit: Sometimes I get a warning like:

Code: Select all

Warning: Illegal PV move g6g5 from Drofa 1.0.1
Warning: Illegal PV move g6g5 from Drofa 1.0.1

Edit2: Once I got:

Code: Select all

Finished game 39 (Drofa 1.0.1 vs OliThink 5.3.3): 1-0 {White wins by adjudication: Invalid result claim}

Perhaps you want to know, that with clang there are some compiler errors. On my Macbook c++ is linked to clang. Many engine compile well with it, but some don't:

Code: Select all

make
c++ -Wall -std=c++11 -O3 -march=native -flto -pthread -fno-exceptions -c -o obj/option.o src/option.cc
In file included from src/option.cc:1:
src/option.h:100:15: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
  std::string _value;
              ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
In file included from src/option.cc:1:
src/option.h:107:15: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
  std::string _type;
              ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
In file included from src/option.cc:1:
src/option.h:112:15: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
  std::string _defaultValue;
              ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
src/option.cc:22:17: error: no member named 'to_string' in namespace 'std'
    _value(std::to_string(value)),
           ~~~~~^
src/option.cc:24:24: error: no member named 'to_string' in namespace 'std'
    _defaultValue(std::to_string(value)),
                  ~~~~~^
src/option.cc:37:21: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
std::string Option::getValue() const {
                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
src/option.cc:41:21: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
std::string Option::getType() const {
                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
src/option.cc:45:21: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
std::string Option::getDefaultValue() const {
                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
src/option.cc:57:35: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
void Option::setValue(std::string value) {
                                  ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
In file included from src/option.cc:1:
In file included from src/option.h:4:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/map:442:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:15:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/iterator:417:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__functional_base:19:
/Library/Developer/CommandLineTools/usr/include/c++/v1/utility:320:9: error: implicit instantiation of undefined template 'std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >'
    _T1 first;
        ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:624:16: note: in instantiation of template class 'std::__1::pair<const std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >, Option>' requested here
    value_type __cc;
               ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:762:23: note: in instantiation of template class
      'std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>' requested here
    __node_value_type __value_;
                      ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:1830:49: note: in instantiation of template class
      'std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>, void *>'
      requested here
        destroy(static_cast<__node_pointer>(__nd->__left_));
                                                ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:1821:3: note: in instantiation of member function
      'std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >,
      std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>,
      std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option> > >::destroy'
      requested here
  destroy(__root());
  ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:805:28: note: in instantiation of member function
      'std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >,
      std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>,
      std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option> > >::~__tree'
      requested here
class _LIBCPP_TEMPLATE_VIS map
                           ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
In file included from src/option.cc:1:
In file included from src/option.h:4:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/map:442:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:15:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/iterator:417:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__functional_base:19:
/Library/Developer/CommandLineTools/usr/include/c++/v1/utility:320:9: error: implicit instantiation of undefined template 'std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >'
    _T1 first;
        ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:625:21: note: in instantiation of template class 'std::__1::pair<std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> >, Option>' requested here
    __nc_value_type __nc;
                    ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:762:23: note: in instantiation of template class
      'std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>' requested here
    __node_value_type __value_;
                      ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:1830:49: note: in instantiation of template class
      'std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>, void *>'
      requested here
        destroy(static_cast<__node_pointer>(__nd->__left_));
                                                ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__tree:1821:3: note: in instantiation of member function
      'std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >,
      std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>,
      std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option> > >::destroy'
      requested here
  destroy(__root());
  ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/map:805:28: note: in instantiation of member function
      'std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >,
      std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option>,
      std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>,
      std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, Option> > >::~__tree'
      requested here
class _LIBCPP_TEMPLATE_VIS map
                           ^
/Library/Developer/CommandLineTools/usr/include/c++/v1/iosfwd:193:32: note: template is declared here
    class _LIBCPP_TEMPLATE_VIS basic_string;
                               ^
11 errors generated.
make: *** [obj/option.o] Error 1

[Guenther]

I've always been clear about the origins of my project, thus I've never met cloning accusations. :D

That is the crucial point. If someone releases an open source project, we are free to debate the merits of it with full knowledge. Maybe a project is "too" similar to another, maybe it is not. That can be a discussion, a debate. When you remove the openness, then you run into issues. You can do no wrong if your work is open-source. The cards are all on the table.

That was probably true 5 years or so ago. Meanwhile there are hundreds of open source programs and other hundreds are still waiting at github or gitlab.(dozens of illegal SF e.g. and 'hybrids' taking this and that, but only admitting to be inspired until someone puts their nose onto some parts and says wtf are those parts? Then it was just accidentally and soon will be corrected and blabla) The sheer amount on the table cannot be easily checked anymore, except for braindead copies.

You can get away with an open source fraud better than ever in history. Once the community of engine lovers and testers has already collected and tested one of them it's too late for a check - nothing will be reverted then, no matter what will be discovered. I am tired of it...
The clever ones e.g. just clone parts of old or already forgotten open source programs, or quite old versions of recent ones and still can start with 3000 or more.
Who does the work to look at what is on the table, if the table is as big as a house? And for what for, just to be called a witch hunt?

[OliverBr]

I was very hesitant in posting Drofa 1.0.0 here, because even though it had over 300 elo more than Shallow Blue (engine that i forked), even with
some of the files rewritten completely, i somehow felt that its not entirely different engine.

Thank you for your engine!
I cloned the repo (https://github.com/justNo4b/Drofa) and it works very well under Linux with gcc! I will late make some tourneys with it.

It's really a very nice engine and looks genuine to me. It runs very smoothly the Illegal claim actually was from OliThink 5.3.3
The strength is quite good for a brand new engine. OlIThink 5.0.0 was not so strong. OliThink 4 as strong as Drofa 1.0.1. Here a little tourney, TC 40/30, 3moves variety book:

Code: Select all

   # PLAYER            :  RATING  ERROR  POINTS  PLAYED   (%)    W    D    L  D(%)  CFS(%)
   1 OliThink 5.3.3    :     275     36   395.5     478  82.7  360   71   47  14.9     100
   2 OliThink 4.1.3    :       1     28   238.5     476  50.1  184  109  183  22.9      52
   3 Drofa 1.0.1       :       0   ----   664.0    1432  46.4  538  252  642  17.6     100
   4 OliThink 3.0.7    :    -166     29   134.0     478  28.0   98   72  308  15.1     ---

White advantage = 17.94 +/- 9.83
Draw rate (equal opponents) = 20.60 % +/- 1.21

[Ras]

(dozens of illegal SF e.g. and 'hybrids' taking this and that, but only admitting to be inspired until someone puts their nose onto some parts and says wtf are those parts? Then it was just accidentally and soon will be corrected and blabla)

That's why I state the origins clearly both in the standard authors.txt of the download archive and in the About section of my website. No source code digging and comparing required to figure it out.

[Tord]

re: post link by Tord
- OMG! date of post: 16 Sep 2003, 12:23 and "If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord" ahhh!!! Stockfish wasn't yet created at that time right?

Correct. I didn't start using bitboards until late 2007, if I remember correctly.

By the way, I regret using the type name "Bitboard" in my source code. It should have been "SquareSet" (which is what I'm using in all computer chess software I'm writing these days, like Chess.jl). The bits are just a low-level implementation detail. What the data type represents is just a set of squares, with set operations like union (|) and intersection (&).

I also imagine if Tord would ever watch my youtube series)))

Unlikely, I'm afraid: I don't learn very well from videos, they feel like a waste of time. Still, I applaud the effort: We all learn differently, and learning materials in a variety of formats are useful to the community.

[OliverBr]

Correct. I didn't start using bitboards until late 2007, if I remember correctly.

Glaurung 2 from 2007 is using Bit... "SquareSets". I am not sure about Glaurung 1.2.1 from 2006. Is the source anywhere available?

EDIT: Found something...http://kirr.homeunix.org/chess/engines/ ... G/ARCHIVE/... Glaurung 1.2.1 doesn't look bitboardish.

[maksimKorzh]

re: post link by Tord
- OMG! date of post: 16 Sep 2003, 12:23 and "If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord" ahhh!!! Stockfish wasn't yet created at that time right?

Correct. I didn't start using bitboards until late 2007, if I remember correctly.

By the way, I regret using the type name "Bitboard" in my source code. It should have been "SquareSet" (which is what I'm using in all computer chess software I'm writing these days, like Chess.jl). The bits are just a low-level implementation detail. What the data type represents is just a set of squares, with set operations like union (|) and intersection (&).

I also imagine if Tord would ever watch my youtube series)))

Unlikely, I'm afraid: I don't learn very well from videos, they feel like a waste of time. Still, I applaud the effort: We all learn differently, and learning materials in a variety of formats are useful to the community.

OMG! Tord it's such a great honor for me to talk with you!

By the way, I regret using the type name "Bitboard" in my source code. It should have been "SquareSet" (which is what I'm using in all computer chess software I'm writing these days, like Chess.jl). The bits are just a low-level implementation detail. What the data type represents is just a set of squares, with set operations like union (|) and intersection (&).

I clearly understand your idea and the reasons behind it, but I use "bitboard" to make it easier to understand for noobs like me)

Unlikely, I'm afraid: I don't learn very well from videos, they feel like a waste of time. Still, I applaud the effort: We all learn differently, and learning materials in a variety of formats are useful to the community.

Sorry but I need to disagree. For me reading in 90% of cases is waste of time because I'm too noob to get info from text...
If there was no VICE series by Richard Allbert I swear I would NEVER EVER learn anything at all.
Only thanks to his series I can now give something back to the community.

Humble request:
Could you please have a very quick look at the code (I know it would make you sick, I'm sorry for that in advance)
https://github.com/maksimKorzh/chess_pr ... _GUI/bbc.c
Don't hate me for global variables and poor C techniques - this is done in order to give noobs like me a chance to learn at least something)

[mvanthoor]

I clearly understand your idea and the reasons behind it, but I use "bitboard" to make it easier to understand for noobs like me)

Well... it depends on how you're writing your engine. In mine, SquareSets would be a completely wrong name, because there are variables that hold entire ranks, files, a single square, a piece, or even sometimes a set of pieces. For many people in chess programming, a "bitboard" is both a "board representation using pieces and squares represented as bits", and also "a variable where each bit means something special". I have even also the term "bitboard, meaning the second definition, outside of chess programming. (Maybe a better name would be a Bitvar or something.)

[No4b]

I was very hesitant in posting Drofa 1.0.0 here, because even though it had over 300 elo more than Shallow Blue (engine that i forked), even with
some of the files rewritten completely, i somehow felt that its not entirely different engine.

Thank you for your engine!
I cloned the repo (https://github.com/justNo4b/Drofa) and it works very well under Linux with gcc! I will late make some tourneys with it.

It's really a very nice engine and looks genuine to me. It runs very smoothly the Illegal claim actually was from OliThink 5.3.3
The strength is quite good for a brand new engine. OlIThink 5.0.0 was not so strong. OliThink 4 as strong as Drofa 1.0.1. Here a little tourney, TC 40/30, 3moves variety book:

Code: Select all

   # PLAYER            :  RATING  ERROR  POINTS  PLAYED   (%)    W    D    L  D(%)  CFS(%)
   1 OliThink 5.3.3    :     275     36   395.5     478  82.7  360   71   47  14.9     100
   2 OliThink 4.1.3    :       1     28   238.5     476  50.1  184  109  183  22.9      52
   3 Drofa 1.0.1       :       0   ----   664.0    1432  46.4  538  252  642  17.6     100
   4 OliThink 3.0.7    :    -166     29   134.0     478  28.0   98   72  308  15.1     ---

White advantage = 17.94 +/- 9.83
Draw rate (equal opponents) = 20.60 % +/- 1.21

Thank you very much for testing and you kind words. By you error messages it looks like clang do not have "std" library witch is heavily used in Drofa (and in SB). For now i cant do much about it, but i`ll take a note of it.

Illegal PV-move issue is known to me. When smth like 3-fold, 50-x move or (rarely) mate detected by Drofa, it would still try to fill PV to the depth needed, thus writing illegals here. Since it currently do not affect the way it plays, i just didn`t bother to fix it.
I still has a bunch of such little bugs, some of the are legasy of the ShallowBlue, and some of them are my own creation

Drofa 1.0.1 isnt the latest version (i`m just lazy with GitHub uploads), i`m at 1.2.9 and its really close to being 2.0.0 release ,with estimated strenght of ~2350 (latest 20-games match with GooglePlex StarThinker finally was a draw and not one-sided beating after i added promotions in the QSearch and improved time management). If you want to take another look, i updated master yesterday (i think) to the 1.2.9.

To be fair though, Drofa cant be counted as a brand new engine (at least in my eyes), because most of the ground work (move generation, bitboards etc) was done in the Shallow Blue already, up till version 1.0.0 i mostly fixed bugs, rewrote hash (because SB implementation was terrible, to be fair) and did eval refactoring to be for my taste (i used PSQT similar to one i used in my chess variant engine), as well as implemented some minor improvements (like QS movegeneration and Null move pruning).

My current way to 2.0.0 is also a couple of bugfixes, but mostly it is search patches; they also couldnt be considered original IMHO, esp LMR and LMP formulas, which are currently very close to Weiss (but not 100%, because copy-paste formulas was not perfect for Drofa`s elo).

My hope is that somewhere on the way to the 3.0.0, where i start to work on eval (i already have a couple of interesting ideas) and other things ( fe I want to train NN for a time management as a way to learn NNs), Drofa can really start to unique and interesting.

[OliverBr]

Well... it depends on how you're writing your engine. In mine, SquareSets would be a completely wrong name, because there are variables that hold entire ranks, files, a single square, a piece, or even sometimes a set of pieces. For many people in chess programming, a "bitboard" is both a "board representation using pieces and squares represented as bits", and also "a variable where each bit means something special". I have even also the term "bitboard, meaning the second definition, outside of chess programming. (Maybe a better name would be a Bitvar or something.)

In OliThink 5 there is no piece list, there are just two 64-bit arrays:

Code: Select all

u64 pieceb[8];
u64 colorb[2];

They represent entirely any position on the board (except some volatile flags like castle/en-passant).
Now I am wondering if those are bitboards, squaresets or bitvars?