Chess program names?

[tpetzke]

For mACE it took pretty long, because it was just starting chess programming and had the idea to implement rotating bitboards. I managed to do that but it took some time.

For my current engine iCE I was much faster. In addition you have a nice test possibility for correctness, which makes the move generator one of the easier parts in an engine.

Thomas...

[Evert]

Durandal has been coded for almost a week now, and still does not have a move generator.

I am a lazy programmer.

The Fire movegen is correct and fast - no point reinventing the wheel.

My point was, you're not saving any meaningful amount of time by keeping the move generator if you're going to redo the search and evaluation anyway, since those take much more time and are much more complicated.

You say you're a lazy programmer and see no point in reinventing the wheel, but that argument can be applied to the search and evaluation equally well (perhaps better).

I said writing the move generator for Leonidas took a day or so. The move generator for Jazz (actually, the first one it had, using rotated bitboards) took longer, maybe a couple of evenings. It's been thoroughly tweaked, optimised and partially re-written since, but the amount of time I have spent on the move generator is still negligible compared to the time I've spent on search and evaluation.

You're of course free to do whatever you want with an open-source engine (as long as you respect the original license), I just find the motivation for keeping the move generator while replacing the search and evaluation odd.

EDIT:
As for names, it doesn't really matter. Pick something you like and just use that. On my hard disk Jazz is still called "Chess2009".

[ZirconiumX]

So - we need a new name, and me and Dmitri can't think of any good ones. (Crossbow is our current best, which isn't great)

Sorry to spoil your party, but the name is not the first thing to think about. Ponder on that proverb instead:

First solve the problem, then write the code

I am doing exactly as this proverb says. I am solving the problem of the name.

Do you have the vaguest idea what it entails to rewrite Fire from scratch (even search and eval "only") ?

Actually, yes. A lot of hard work, much criticism from people who haven't got their engines that far, and much support from people who have.

I'm pretty sure that you don't, and it's not by taking other programs, putting your name on them and making trivial modifications that you will ever learn anything. Learning requires humility and time, there's no magic shortcut.

There never is.

When I look at FruitFly and Durandal, it was the same story:
- Fruitfly is basically Fruit 2.1 with a few trivial modifications, that essentially lost a few hundreds of elo in an ill advised attempt to improve it, and caused serious bugs too. If you don't understand how a simple wheel work, you will never be able to modify the engine of a Ferrari. If I were you I would have kept this one *real quiet*, because doing this to Fruit is not something to be proud of. It's comparable to spray painting a Van Gogh or defecating on a wedding cake. Again, you put the carriage in front of the horse: (i) writing code without understanding where you're going (ii) finding a new name for the program and calling yourself its author.

At that time, I didn't have the resources to test code. I had an outdated iMac with 1 core. (and using your rule of concurrency = number of cores - 1, I have 0 cores to test with.)

- Durandal: Again you start from the name, but you don't have the vaguest clue on how you're going to build it. Even the board representation and move type definition is not clearly understood (let's not even talk about a move generator at this point).

I admit, I have not had time to focus on Durandal for several reasons.

- Firenzina: a few trivial modifications, the first being to put your name on it, and again not the vaguest clue how to do anything with this source code that you don't understand. When I look at the git repo, I don't see any functional modification. Other than renaming stuff and adding or moving around some files, it's still Fire 2.2 by Kranium and Sentinel.

This is a lie. Take Fire 2.2 and try and compile it on Linux. I got 22,005 errors. Try and compile the latest git source on Linux. It compiles cleanly.

Some people reading this post may think I'm harsh, but it's the reality. Look for yourself if you don't believe me:
https://github.com/ZirconiumX/fruitfly
https://github.com/ZirconiumX/Durandal
https://github.com/Censor/Firenzina

Look in there if you want. That's me.

You can read all you want in the chess programming wiki, and forum post, but the reality is: until have written a chess engine yourself, you basically don't know/understand anything. There are so many things that look "simple" in theory, and you'll have to figure out in a real implementation. Simply doing a qsearch() correctly already is full of pitfalls and tradeoffs. I'm not even talking about implementing a hash table, where most newbies get it wrong. And that's just the ABC of the search...

[COMMENT DELETED]

PS: I don't know about Dmitri, because (so far), he hasn't written a single line of real code in Firenzina. But given the way he's been parading with Firenzina on this forum, it's quite obvious that he's just as clueless as Matthew...

This is a lie. He has not done a huge amount of earthworks in the code, I admit, but he has done a few things.

PPS: Please don't compare anything you do to DiscoCheck. It's just not even comparable.

[COMMENT DELETED]

We seem to be in a vicious circle. I get enough motivation (which is pretty hard with people like you around) to write some code. It's criticised. I write the code again. It's criticised. I write the code again. It's criticised. I abandon the code because of the lack of motivation to carry on.

Every time. Every single time.

You can read all you want from a psychology book, but the reality is: until you have experienced it yourself, you basically don't know/understand how it feels.

If I wanted someone to criticise me in what I enjoy doing, I'd pay for a critic.

Matthew:out

[Evert]

Sometime ago I had a look at your source code. Seriously, you have taken a lot more from others than Vasik ever took from Fruit. Bottom line, if you fingerpoint to people there are still 4 fingers pointing to yourself.

We'll probably want to stay clear of yet another tiresome Fruit/Rybka debate. Important to keep in mind: it's perfectly fine (ie, legal) to use ideas (or even code) from an open source project in another open source project. There are no fingers to point at anyone doing that.

I see 2 young programmers finding their way in computer chess programming using open sources being totally transparent, what possibly can be against that?

Nothing, of course.
There would be something wrong with taking an open source engine (say, Stockfish), renaming it and sticking my own name on there in place of the original author's name.

Not saying something like that is happening here, but there appears to be some concern that there seems to be more focus on a new name for a fork (actually a fork of a fork) of an open source engine than on actual improvement of said engine. The latter would of course be (much) more interesting.

Again, that's not saying that there won't be improvement, or at least changes, to the program. It just seems that it would make more sense to make the changes and then worry about a new name rather than the other way around.

It may be worth revisiting the announcement of Stockfish 1.0, http://www.talkchess.com/forum/viewtopic.php?t=24675 (already an old thread when I found it). It's easy to forget today that Stockfish is a fork of Glaurung, still an active engine at the time. In particular, note that it wasn't just Glaurung renamed as Stockfish, there were already actual changes in the engine.

[ZirconiumX]

Fire is a brilliant engine, it is strong (in a 1000 game test, it was 97 elo stronger than Stockfish, somehow), and has a very good eval.

However, in my opinion, and it seems in Dmitri's opinion too, the code is difficult to read and understand. This is why I am rewriting the eval and search.

Of course, I may well be wrong.

Matthew:out

[Rebel]

Sometime ago I had a look at your source code. Seriously, you have taken a lot more from others than Vasik ever took from Fruit. Bottom line, if you fingerpoint to people there are still 4 fingers pointing to yourself.

We'll probably want to stay clear of yet another tiresome Fruit/Rybka debate.

I think it's hypocritical to scapegoat 2 programmers while doing the same thing.

Important to keep in mind: it's perfectly fine (ie, legal) to use ideas (or even code) from an open source project in another open source project.

Precisely, no arguments here.

[lucasart]

Sometime ago I had a look at your source code. Seriously, you have taken a lot more from others than Vasik ever took from Fruit. Bottom line, if you fingerpoint to people there are still 4 fingers pointing to yourself.

My code is open source and freely available to anyone who wishes to compile, study or modify it. It is released under the GNP GPL v3, and that means I can perfectly copy verbatim all the code that I want from a GPL engine. The whole idea of the GPL is to protect open source (from people like Vasik, who turn it into proprietary software) and to promote the sharing of code.

Rybka, on the other hand, is a proprietary program. The source code is closed, and it is released under a freedom suppressive license. Copying code from the GPL program Fruit into Rybka is a clear violation of the GPL. It doesn't matter how much code.

Now to come back to DiscoCheck, here's the code that I copied:
1/ the code that generates the magic bitboards is from Umko, by Borko Boskovic.
2/ the SEE is from Glaurung 2.1, by Tord Romstad.

I have never tried to hide this, or to deny it. On the contrary, it is documented in the source code. At the scale of the entire code, these parts are fairly small. At least in lines of code. If we look at it in terms of how much time and effort it would have been to do by myself, then Magic bitboard is really the biggest part (although it contributes to zero elo in itself, it makes subsequent operations on occupancies much easier/cleaner).

Now if you think that 1/ and 2/ are a "lot more than what Vasik took from Fruit", the question becomes: how much did Vasik take from Fruit? I have neither time nor interest to debate this point with you. But when I read your never ending posts, or articles on your website about that subject, I realize that you have nothing but time...

[velmarin]

But when I read your never ending posts, or articles on your website about that subject, I realize that you have nothing but time...

You should apologize, with Matew, Ed and Dmitri,

You have raised the issue of context.
It was a fun issue, quite community visited and wrote answers.

You have all your project and we respect that.
Please respect those of others, I do not care where you copy your codes, copy or not.
Respect your work so it is a labor of love by Chess.
Follow with your project and let the fights.

By the way, would dare you to improve Fire o IvanHoe , would be a challenge.
If only a few ELO points.

[ZirconiumX]

But when I read your never ending posts, or articles on your website about that subject, I realize that you have nothing but time...

You should apologize, with Matew, Ed and Dmitri,

You have raised the issue of context.
It was a fun issue, quite community visited and wrote answers.

You have all your project and we respect that.
Please respect those of others, I do not care where you copy your codes, copy or not.
Respect your work so it is a labor of love by Chess.
Follow with your project and let the fights.

By the way, would dare you to improve Fire o IvanHoe , would be a challenge.
If only a few ELO points.

That's a valid point, José.

Lucas, before you criticise ME for not doing anything, prove that you can do much better.

Then I will accept your criticism.

Matthew:out

[lucasart]

By the way, would dare you to improve Fire o IvanHoe , would be a challenge.
If only a few ELO points.

It's *very hard* to improve such engines! Even by a few elo. That is why, I am saying that Matthew and Dimitry, given their lack of experience, should start with a more modest goal.

I find the IvanHoe source code (or any Ippo engine) truly horrible. Yes, it's a very strong engine elo-wise, but the source code is really an un-maintainable mess. At least it doesn't make *me* want to maintain it.

The only strong open source engine I would like to toy with is Stockfish. The problem is that I don't have time at my disposal:
- first, I would have to stop DiscoCheck, and dedicate my 8-cores only to testing SF patches
- second, it's not fun! Everything in Stockfish is already done and so well optimized. The only room left for improvement is minor tweaks that take a few minutes to code, and several days to test. It's 0.1% code, and 99.9% CPU testing time, and waiting... In DiscoCheck, there are still many things to improve, and even to rethink. One really big work will be to implement SMP, but the task is really daunting, so I've always post-poned it.

Regarding apologies, I was perhaps a bit harsh on Matthew, especially given his young age. But one I will *not* apologize to is Ed Schroder... The eternal Rybka/Fruit spammer... The one who single handedly fills the EO forum...