Is cloning a hobby?

[Tony P.]

I assumed that there will eventually be many NN engines that won't be forks of SF nor Leela (nor Scorpio, though you're not mentioned there). That said, you're indeed credited in RubiChess, Igel, and Minic

Another consideration that I neglected, though, is that TB probing is considered such a small part of an engine that no one bothers to find out how closed-source engines do it (David Carteau does acknowledge that the 'Syzygy support' isn't '100% original' in Orion 0.7, but as far as I understand, he seems eager to write his own TB code soon anyway and possibly even to open the source, so it's only a tiny issue that he forgot to add the MIT license file even if he did use Fathom/Pyrrhic instead of Ronald's original probing code.)

[amchess]

Is that true though? Are you saying this because it has a "tactical mode", or because you've looked at the source code? Because the source code is out.

Both of them!
I've not only looked at the source code, but even translated in english from dutch.
Tactical part is more than what you illustrated and I can show you.
Anyway, no tactical fork of stockfish had the same results in hard positions solving and even now it solves a lot more positions than other engines like Crystal derivate, etc.
In my opinion, to develop a strong engine, we need a lot of testers to be rigorous and this is the true hard part of engines development, in terms of time!
Thanks to God, I have testers and my ShashChess, only after two years of hard work, solves more positions!
So, even if mostly the code is from Stockfish, I appreciate this part of code.
Someone can violate a gpl licence and I don't like at all it like you, but not necessarily all his code is without any value.
We have to distinguish, in my opinion, between ethical and technical domains.
For Fire, it seemed to me it's an Ivanhoe derivate, but perhaps I'm wrong...

Andrea

[Alayan]

I assumed that there will eventually be many NN engines that won't be forks of SF nor Leela (nor Scorpio, though you're not mentioned there). That said, you're indeed credited in RubiChess, Igel, and Minic

Some concepts I showed successful in Ethereal (some being taken from Stockfish, some original) were adopted in Xiphos, Arasan, RofChade, Combusken

Engine authors look at what others are doing for inspiration, and sometimes it works for them too. it's a positive interaction, this idea sharing is not systematic enough to threaten originality of classical eval or search of engines made by people who want an original engine, not a mere derivative.

[MikeB]

My personal definition of some of the terms are:

- Clone -> An engine which is a copy of another engine, with only minor differences. (Think: LMR tweaks, PSQT replacements, some additions, deletions, or changes to the search or evaluation, that sort of thing.)

- Port -> an engine rewritten in a different language with the intention of making an exact copy as possible, from the old to the new language. (This will make the new engine a clone as well.) Examples would be CFish, RustFish and ASMFish. However, such a port can also evolve to become a derivative.

- Derivative -> An engine that started out as a clone, but has diverged to such an extent that it is clearly very different from the source, but it does still shows heavy influence of that source. If it diverges even further to become almost unrecognizable as a derivative, it may become an original engine.

- Original -> An engine written from scratch. It can use many known concepts (alpha/beta, PSQT-tables, null move...), but also its own implementation of ideas from other engines. It is possible for a derivative to be rewritten to such an extent that it becomes an original engine because most or all of the source of the parent engine is gone.

As I said earlier... the question then becomes WHEN an engine transitions from clone to derivative. and from derivative to original. I think Weiss is an engine that's clearly on that path. It started out as a VICE clone. It evolved from a mailbox engine into a magic bit board engine, but VICE influences were still apparent if you know both engines. It has had extensive changes to its search and evaluation, and big parts of the rest of the code have been rewritten. Weiss is either close to being an original engine now, or it's already there.

(It's even possible for an engine to evolve in the other direction: start out as an original, and then taking so many concepts and ideas of other engines, implementing them the same way as the other engines do, that it becomes a mashup of different engines instead of being original. It seems the just discussed BEEF may be in this category. What name should that have? FrankenEngine?)

+1 Excellent post, it changed my thinking.

[MikeB]

Pyrrhic will put Andrew's name on more engines than the rest of Ethereal would.

I think you may be surprised actually. Almost every open-source engine thats 1) Not Stockfish, and 2) Not a Leela fork, has Ethereal mentioned in small or large parts. I think Ethereal has become the Stockfish of learning. Once you have a working engine, then you can go take snippets from Stockfish.

Interesting observation - I'm not surprised. Ethereal is perhaps the best commented source for an engine in active status. Good work - very much appreciated it.

[mvanthoor]

+1 Excellent post, it changed my thinking.

Cool, thanks for the props

Interesting observation - I'm not surprised. Ethereal is perhaps the best commented source for an engine in active status. Good work - very much appreciated it.

it is? Shame that I've not yet looked at it, as to try and keep as much of my own engine from scratch as possible by just reading about all of the concepts. I'll have to look at it some day.

Even so, even if I never reach the top 10 of the rating lists, I'll try and make my engine's documentation extensive... not only by commenting the source (which I do as I go), but also by writing a full-blown book/tutorial about it. I fully intend for Rustic to try and become one of the reference engines. (It is one of the reasons why I've chosen Rust: there are already engines with extensive documentation, in C.)

[OliverBr]

If he shares the source code where is it?
I did not see it on github.

https://github.com/jtseng20/Beef

Unfortunately Beef from this repository doesn't compile...

Code: Select all

....
search.cpp:269:15: error: no member named 'pv' in 'searchInfo'
        info->pv[0] = MOVE_NONE;
        ~~~~  ^
search.cpp:407:15: error: no member named 'pv' in 'searchInfo'
        info->pv[0] = MOVE_NONE;
        ~~~~  ^
1 warning and 13 errors generated.
make: *** [search.o] Error 1

[OliverBr]

This (from the Beef github page) sounds pretty remarkable:
"Beef implements many features found in popular modern engines, built around an original legal-move-only move generation scheme which aims to make search as fast as possible — using this design, the startpos perft speed at one point reached 385 mnps (1 CPU, no hash)! Therefore, Beef mainly hopes to achieve its playing strength from search speed."

Yes this was also the original idea with Olithink: To start with a very fast legal-move-only move generator and build the engine around it. The other idea was not to use any chess knowledge other than a simple mobility eval.

Of course, Beef is much stronger than OliThink.

See oliperft (https://github.com/olithink/OliThink/tree/oliperft) which makes 285 mnps (1 CPU, no hash, I commented the hash parts for this purpose):

Code: Select all

 1     0      0          20
 2     0      0         400
 3     0      0        8902
 4     0      0      197281
 5     0      2     4865609
 6     0     46   119060324
 7     0   1166  3195901860

Nodes: 3320034396 cs: 1166 knps: 284615

With hash it is:

Code: Select all

Nodes: 3320034396 cs: 485 knps: 683275

[maksimKorzh]

Isn't it more interesting to walk through the entire path absolutely from scratch - from complete noob to at least working engine and then hopefully gain a skill to learn from stronger engines?

It depends on the personality. One may find some stages of the path boring but necessary for the overall success. Personally, I'm not thrilled about bit twiddling nearly as much as about the higher maths of tuning However, the low-level parts of the design will affect the overall performance too, and they do deserve thinking through, as an exercise in delayed gratification.

I don't even feel that engine I'm now covering in youtube series to be my own even though I'm writing it from blank file and untill it plays chess because even though it has some of my own ideas (more likely making it worse) still every video regarding search I'm giving credits to the sources all the time hence feeling more like learning rather than teaching.

Even if the ideas are weakening your current implementation, they might become bricks in the foundations of future top engines where they'll suddenly work better, you never know

Thank you for the speed test of move generators; it was a surprise to me that a hybrid board representation (that makes eval easier) was almost as fast as pure bitboards. That small idea from Aiki may eventually put your name onto the acknowledgement lists of stronger engines, like Pyrrhic will put Andrew's name on more engines than the rest of Ethereal would.

it was a surprise to me that a hybrid board representation (that makes eval easier) was almost as fast as pure bitboards.

I'd bet that it might be even faster because when I know revising the that 2 years old code I feel depressed... so bad it is...

That small idea from Aiki may eventually put your name onto the acknowledgement lists of stronger engines

That idea was implemented before many times, e.g. people added magic bitboards to TSCP and VICE (Weiss). Even though I didn't know it at that time and "invented" this idea "independently" still it doesn't make it unique because simply adding pre-calculated attack tables and rewriting movegen and altering makemove function is not that big deal.

Anyway thanks for your feedback, that's flattering)

[Gabor Szots]

https://github.com/jtseng20/Beef

Unfortunately Beef from this repository doesn't compile...

Code: Select all

....
search.cpp:269:15: error: no member named 'pv' in 'searchInfo'
        info->pv[0] = MOVE_NONE;
        ~~~~  ^
search.cpp:407:15: error: no member named 'pv' in 'searchInfo'
        info->pv[0] = MOVE_NONE;
        ~~~~  ^
1 warning and 13 errors generated.
make: *** [search.o] Error 1

[/quote]

Same here. However, version 0.2.2 compiled all right.