info about Fruit

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 11:48:47:


Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Good thing that Dann released a version yesterday, I gain half a day then.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
I will make sure Winboard users have some way of running my engine. If all fails, I will add Winboard support to the code, although this is against my design goals (code quality).
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
It is true that I claim my engine is weak, because I know all that's missing from the code (few examples below).
But it is a completely untested engine, maybe it is good, I just don't expect it to be.
Example, what's in the eval:
- piece-square table
- static pawn eval (only basic pawn types, no interaction with pieces)
- 3 or 4 boolean features like "if there an "own pawn" along my "forward" bishop diagonals" (negative score)
That's all!!!
No king safety, no mobility of any kind, no connected passers, *no knowledge of drawish endgames*!
How could such a program play decent chess I do not know, it's not even fast.
Search:
R=3 nullmove, extend all check evasions 1 ply, try all checks 1st ply of quiescence.
That's all!!!
No other extension.
No parameter tuned, nothing tested!
After the release I will test several combinations of search parameter.
If I have time next week-end I will add them as UCI options so people can play with it.
In commercial programs they are already tuned so you can't improve the program.
Totally opposit here, may I hope users will send me good parameters? ))
I have only one computer for testing, please Aaron Gordon where are you!
I have a bad feeling about people getting too hopeful and will be disappointed when they realise Fruit's true level, you have been warned.
May I add I have for instance statistical proof that Gothmog is stronger (at least in 5 0)?
I am not ashamed, I have great hope for Gothmog!!!
Now I am hopeful for the near future. I think adding a few well chosen features in the eval should help.
My philosophy was to release early (next week), and only then to work on the missing knowledge.
I intend to observe what missing knowledge hurts most in test games and add it, little by little.
As of now I am thinking of known drawish endgames (some KXKY and of course KNNK), that I see very often in test games.
Also a pawn-shelter code I am sure would help its king not getting crushed so often by Gothmog
This post is a bit disorganised, as I try to answer various independant questions.
Let's continue with a few more answers:
Fruit is my third chess engine.
As I do for other projects (e.g. Othello), I start from scratch again every few years.
The code quality is much better than a single program improving over say 15 years.
I am french and live in Cambridge UK at the moment.
I feel like my citizenship is "european".
I might live in Italy in two years
Yes I believe I can improve Fruit easily for the next version.
See what I said about all the missing knowledge.
The source code will be made available on Dann's site when he gets up, you will be able to check for yourself.
He did not know I was going to release it open-source.
Oh, the name is Fruit of course, not Fruit_src; please rename it.
I will answer questions here, rather than trying to answer all in one go.
Bye for now, waiting for reactions.
Fabien.

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 12:18:24:
Als Antwort auf: / In reply to: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 11:48:47:


I forgot the most important things (the ones that were not asked):
Design goals for Fruit are (more important first):
- low memory consumption (except hash tables); maybe 256 KB max.
- positional style (boring chess like I play: shuffle pieces, wait for mistake, exchange queens, play endgame); Comet is like this?
- good endgame knowledge
- slow time controls (not tested at all, can't afford it)
This is all far future stuff, *if* I do it at all. A 10-year-old player knows much more than Fruit about the endgame, this is my top priority *in the engine*, but other programs have higher priority right now.
Unfortunately, I have just decided *against using* Nalimov code for several reasons (including code that is not free of use). It is unlikely to change in the future (as a start it is against goal 1, Nalimov code which I used in the private version of Fruit was responsible for more than 50% of the engine).
I have no plan to port Fruit to Palms for now although by design it should be "ready" at all times (this will probably require 32-bit platforms though, as I think ARM ones are).
Fabien.

[Matthias Gemuh]

Geschrieben von: / Posted by: Matthias Gemuh at 10 March 2004 12:26:08:
Als Antwort auf: / In reply to: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 11:48:47:

The source code will be made available on Dann's site

Dann's site ???? His site can be accessed (and navigated) by 1% of the
people who try it.
Strangely enough, when he provides direct links to files, they work.
Note that I am aware of "Http://ftp://".
Thanks for Fruit and the yet unreleased uci2wb adapter.
/Matthias.


BigLion + Taktix

[Tord Romstad]

Geschrieben von: / Posted by: Tord Romstad at 10 March 2004 12:30:14:
Als Antwort auf: / In reply to: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 11:48:47:

Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Good thing that Dann released a version yesterday, I gain half a day then.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
May I add I have for instance statistical proof that Gothmog is stronger (at least in 5 0)?
I am not ashamed, I have great hope for Gothmog!!!
Now I am hopeful for the near future. I think adding a few well chosen features in the eval should help.
My philosophy was to release early (next week), and only then to work on the missing knowledge.
I intend to observe what missing knowledge hurts most in test games and add it, little by little.

Welcome!
I could try to port your adapter to Mac OS X, if you want (probably a
trivial task). It seems like a useful tool.

Interesting. What you write above is an almost exact description of my
own situation when I released my engine last year, except that my code
had been sleeping for three or four years by the time I picked it up
again. I'm still not sure what all the old code does, but somehow it
seems to work (which is almost unbelievable, considering how the code
looks).


Considering Dann's data, I don't really believe this is true. It is
more likely that Gothmog is a particulary difficult opponent for Fruit.
You write that you have no king safety at all at the moment. This
probably makes Fruit very vulnerable to Gothmog's primitive and
one-dimensional attacking style of play.


This sounds like a good approach. My biggest problem in chess programming
has always been my lack of patience. I always want to add everything at
once, and I never test as carefully as I should.
Good luck with Fruit! I look forward to seeing your engine in action,
and to follow the development.

Tord

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 12:51:11:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Matthias Gemuh at 10 March 2004 12:26:08:

Dann's site ???? His site can be accessed (and navigated) by 1% of the
people who try it.
Strangely enough, when he provides direct links to files, they work.
Note that I am aware of "Http://ftp://".
Thanks for Fruit and the yet unreleased uci2wb adapter.
/Matthias.

Dann's site is crippled by a firewall. Directory lists are very hard to obtain ("wget" can get them, for connoisseurs). Most mortals can download files, but not see directory contents. Note that it is independent of Dann's will (sorry, litterally-translated french expression), he must be very unhappy about it!
About UCI2WB don't hold your breath. It needs about two week-ends of work on Linux, and then the port to Windows is going to be a big problem; the only thing I can promise is a release for unix-compatible operating systems (e.g. Linux, MacOS X). Of course if I have Dann - the magician - Corbit on my side anything can happen
Also I am in contact with Roland Pfister, author of WB2UCI as you know it. We can probably fix the "multiple time control" bug. Fruit should be able to work with it then.
Can somebody test Fruit + WB2UCI + Winboard now? *do not use multiple time controls*, like 40 in 5. Use sudden death; increments should work.
As you can see I try to do too much at the same time, let's just hope I can do it
Fabien.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 10 March 2004 12:55:09:
Als Antwort auf: / In reply to: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 11:48:47:

Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Good thing that Dann released a version yesterday, I gain half a day then.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
I will make sure Winboard users have some way of running my engine. If all fails, I will add Winboard support to the code, although this is against my design goals (code quality).
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
It is true that I claim my engine is weak, because I know all that's missing from the code (few examples below).
But it is a completely untested engine, maybe it is good, I just don't expect it to be.
Example, what's in the eval:
- piece-square table
- static pawn eval (only basic pawn types, no interaction with pieces)
- 3 or 4 boolean features like "if there an "own pawn" along my "forward" bishop diagonals" (negative score)
That's all!!!
No king safety, no mobility of any kind, no connected passers, *no knowledge of drawish endgames*!
How could such a program play decent chess I do not know, it's not even fast.
Search:
R=3 nullmove, extend all check evasions 1 ply, try all checks 1st ply of quiescence.
That's all!!!
No other extension.
No parameter tuned, nothing tested!
After the release I will test several combinations of search parameter.
If I have time next week-end I will add them as UCI options so people can play with it.
In commercial programs they are already tuned so you can't improve the program.

I really do not understand.
I have king safety
I have mobility based on number of moves.
I thought they are important.
maybe the 3 or 4 boolean features that I do not have are important.
What do you mean that is all?
What about order of moves(maybe it is better than other engines?)
I am sure that it is possible to improve commercial programs and the results that I read suggest that commercial programs are extremely weak.
I did not test fruit against movei but based on reading Dann's post I got the impression that my movei is at similiar level to fruit and movei proved to be not without chances against commercial programs.
I guess that you have some advantages like better order of moves and better use of hash tables relative to me.
I am sure that the way that I use hash tables is extremely bad relative to other programs.

Uri

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 13:05:47:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 12:51:11:

Also I am in contact with Roland Pfister, author of WB2UCI as you know it. We can probably fix the "multiple time control" bug. Fruit should be able to work with it then.
Can somebody test Fruit + WB2UCI + Winboard now? *do not use multiple time controls*, like 40 in 5. Use sudden death; increments should work.

My bad, it is UCI2WB of course, my engine is UCI-only.
Fabien.

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 13:31:36:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Uri Blass at 10 March 2004 12:55:09:


Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
I will make sure Winboard users have some way of running my engine. If all fails, I will add Winboard support to the code, although this is against my design goals (code quality).
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
It is true that I claim my engine is weak, because I know all that's missing from the code (few examples below).
But it is a completely untested engine, maybe it is good, I just don't expect it to be.
Example, what's in the eval:
- piece-square table
- static pawn eval (only basic pawn types, no interaction with pieces)
- 3 or 4 boolean features like "if there an "own pawn" along my "forward" bishop diagonals" (negative score)
That's all!!!
No king safety, no mobility of any kind, no connected passers, *no knowledge of drawish endgames*!
How could such a program play decent chess I do not know, it's not even fast.
Search:
R=3 nullmove, extend all check evasions 1 ply, try all checks 1st ply of quiescence.
That's all!!!
No other extension.
No parameter tuned, nothing tested!
After the release I will test several combinations of search parameter.
If I have time next week-end I will add them as UCI options so people can play with it.
In commercial programs they are already tuned so you can't improve the program.
Totally opposit here, may I hope users will send me good parameters? ))
I have only one computer for testing, please Aaron Gordon where are you!
I have a bad feeling about people getting too hopeful and will be disappointed when they realise Fruit's true level, you have been warned.
May I add I have for instance statistical proof that Gothmog is stronger (at least in 5 0)?
I am not ashamed, I have great hope for Gothmog!!!
Now I am hopeful for the near future. I think adding a few well chosen features in the eval should help.
My philosophy was to release early (next week), and only then to work on the missing knowledge.
I intend to observe what missing knowledge hurts most in test games and add it, little by little.
As of now I am thinking of known drawish endgames (some KXKY and of course KNNK), that I see very often in test games.
Also a pawn-shelter code I am sure would help its king not getting crushed so often by Gothmog
This post is a bit disorganised, as I try to answer various independant questions.
Let's continue with a few more answers:
Fruit is my third chess engine.
As I do for other projects (e.g. Othello), I start from scratch again every few years.
The code quality is much better than a single program improving over say 15 years.
I am french and live in Cambridge UK at the moment.
I feel like my citizenship is "european".
I might live in Italy in two years
Yes I believe I can improve Fruit easily for the next version.
See what I said about all the missing knowledge.
The source code will be made available on Dann's site when he gets up, you will be able to check for yourself.
He did not know I was going to release it open-source.
Oh, the name is Fruit of course, not Fruit_src; please rename it.
I will answer questions here, rather than trying to answer all in one go.
Bye for now, waiting for reactions.
Fabien.
---

I really do not understand.
I have king safety
I have mobility based on number of moves.
I thought they are important.
maybe the 3 or 4 boolean features that I do not have are important.
What do you mean that is all?
What about order of moves(maybe it is better than other engines?)
I am sure that it is possible to improve commercial programs and the results that I read suggest that commercial programs are extremely weak.
I did not test fruit against movei but based on reading Dann's post I got the impression that my movei is at similiar level to fruit and movei proved to be not without chances against commercial programs.
I guess that you have some advantages like better order of moves and better use of hash tables relative to me.
I am sure that the way that I use hash tables is extremely bad relative to other programs.

Uri,
It is very hard to answer you, because it looks like you think in a different way.
I think king safety and mobility are vital features.
My engine does not know about open files.
There is a single boolean feature for rooks: if there is a "own" pawn somewhere in front of it (same file) there is a negative bonus (malus?) for the rook.
Of course open files are more important!
Do you think I did not add them to give my program a handicap?
Of course not!
When I wrote my program a year ago, I was testing search features, such as checks in quiescence.
My goal was to study "chess trees", not to write a competition program.
You will see in the source code: there are files for mate searches (nothing like Chest mind you, more like "an engine without eval") or material-only searches, they are not used by the engine!
Because of that, Dann thought I was not using hash tables ))
I only added the minimum to the eval, to keep things somewhat simple.
Now I start testing the program and maybe it plays decent chess; I want to release "as is" anyway.
I am sure the following version will contain a "fairly normal" eval.
All I didn't describe is because it's the "normal" implementation, nothing special.
Move ordering is the "basic" trans-table move then MVV/LVA captures then 2 killers then history.
For more details wait for Dann to publish the source code please, I won't describe each line for you.
I am 100% sure there is nothing better than an average engine in there.
I think the difference is "design goal" and "consistency".
For example I want my search to be "stable". Many things I don't do like:
- updating alpha and beta when a hash hit does not cause a cutoff (notice this is only at PV nodes anyway).
- actually I don't ever cut-off at PV nodes!
"the PV must always be complete" is one of my design choices. The position at the end of the PV must evaluate to the search value or else I have a bug.
Not beta-cutting at PV nodes, that costs me I'm sure. Sometimes Fruit announces mate, but can't find it at the next move (but maybe the mate was imaginary then).
I think most engines don't have design goals, rather the author tries to improve this and that. I believe in consistency, if all of your engine-modules work together for a goal you can't go so very wrong?! I hope so anyway
About Movei; I can't test it of course I only have linux. I am convinced Movei is stronger. But please don't think "is Movei stronger?" "why is this engine better?" all day, we (programmers in general) have different engines that's all, let's celebrate that!
My hash tables are nothing special. Note depending of what Dann did, it only uses 16 MB, the UCI option does not affect hash table size in the code version that Dann has.
I do 4 probes, and always replace the shallowest entry.
I repeat; I did not describe the rest because it is IMO well-known "normal" implementation.
So in random order I use PVS, ETC, verified null move (not as described in the article, just normal null move then normal depth-reduced search without null move to check). Verification is only used in endgame.
Uri,
Although I have trouble understanding your posts (and not because of engline), I will try to answer your questions.
Bye for now,
Fabien.

[Volker Pittlik]

Geschrieben von: / Posted by: Volker Pittlik at 10 March 2004 13:31:51:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 12:51:11:

...

Also I am in contact with Roland Pfister, author of WB2UCI as you know it. We can probably fix the "multiple time control" bug. Fruit should be able to work with it then.
Can somebody test Fruit + WB2UCI + Winboard now? *do not use multiple time controls*, like 40 in 5. Use sudden death; increments should work.

Good news.
I'll try it. In the meantime a result played under Arena (Fruit used a book made by me):


.
No. Name            Win Draw Loss Unf.  Score Games       %
-----------------------------------------------------------
.1 Fruit            +4   =1   -5   *0    4.5    10   45.0%
.2 Dragon_45        +0   =0   -2   *0    0.0     2    0.0%
.3 ELChinito 3.25   +1   =1   -0   *0    1.5     2   75.0%
.4 List512          +2   =0   -0   *0    2.0     2  100.0%
.5 Ruffian_210      +2   =0   -0   *0    2.0     2  100.0%
.6 Yace-09982       +0   =0   -2   *0    0.0     2    0.0%
.
Total Games:      10
White Wins:        4 (40.0%)
Black Wins:        5 (50.0%)
Draws:             1 (10.0%)
Unfinished:        0 (0.0%)


Yace and Dragon aren't wimps AFAIK.
Volker

BTW: As I already wrote by mail, I don't have any problems with posts about UCI-only engines or other related software. They seem perfectly on-topic for me.

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 13:42:35:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 13:31:36:


My bad again, ignore the first part of the last post, which was still in my text editor.
I am busy trying to answer everyone, and I make many mistakes.
Fabien.

[Benny Antonsson]

Geschrieben von: / Posted by: Benny Antonsson at 10 March 2004 13:43:38:
Als Antwort auf: / In reply to: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 11:48:47:

Hello !
Is WB-support going to worsen your code quality or why do you only support UCI ?
Will the source be available on Danns FTP ?
/Thanks for an interesting engine !

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 13:44:07:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Volker Pittlik at 10 March 2004 13:31:51:

No. Name Win Draw Loss Unf. Score Games %
-----------------------------------------------------------
.1 Fruit +4 =1 -5 *0 4.5 10 45.0%
.2 Dragon_45 +0 =0 -2 *0 0.0 2 0.0%
.3 ELChinito 3.25 +1 =1 -0 *0 1.5 2 75.0%
.4 List512 +2 =0 -0 *0 2.0 2 100.0%
.5 Ruffian_210 +2 =0 -0 *0 2.0 2 100.0%
.6 Yace-09982 +0 =0 -2 *0 0.0 2 0.0%
.
Total Games: 10
White Wins: 4 (40.0%)
Black Wins: 5 (50.0%)
Draws: 1 (10.0%)
Unfinished: 0 (0.0%)


Yace and Dragon aren't wimps AFAIK.
Volker

I seriously think Dann compiled another program by mistake
Does it really claim to be called "Fruit 0.98a" by me?
Fabien.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 10 March 2004 14:09:05:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 13:31:36:

Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
I will make sure Winboard users have some way of running my engine. If all fails, I will add Winboard support to the code, although this is against my design goals (code quality).
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
It is true that I claim my engine is weak, because I know all that's missing from the code (few examples below).
But it is a completely untested engine, maybe it is good, I just don't expect it to be.
Example, what's in the eval:
- piece-square table
- static pawn eval (only basic pawn types, no interaction with pieces)
- 3 or 4 boolean features like "if there an "own pawn" along my "forward" bishop diagonals" (negative score)
That's all!!!
No king safety, no mobility of any kind, no connected passers, *no knowledge of drawish endgames*!
How could such a program play decent chess I do not know, it's not even fast.
Search:
R=3 nullmove, extend all check evasions 1 ply, try all checks 1st ply of quiescence.
That's all!!!
No other extension.
No parameter tuned, nothing tested!
After the release I will test several combinations of search parameter.
If I have time next week-end I will add them as UCI options so people can play with it.
In commercial programs they are already tuned so you can't improve the program.
Totally opposit here, may I hope users will send me good parameters? ))
I have only one computer for testing, please Aaron Gordon where are you!
I have a bad feeling about people getting too hopeful and will be disappointed when they realise Fruit's true level, you have been warned.
May I add I have for instance statistical proof that Gothmog is stronger (at least in 5 0)?
I am not ashamed, I have great hope for Gothmog!!!
Now I am hopeful for the near future. I think adding a few well chosen features in the eval should help.
My philosophy was to release early (next week), and only then to work on the missing knowledge.
I intend to observe what missing knowledge hurts most in test games and add it, little by little.
As of now I am thinking of known drawish endgames (some KXKY and of course KNNK), that I see very often in test games.
Also a pawn-shelter code I am sure would help its king not getting crushed so often by Gothmog
This post is a bit disorganised, as I try to answer various independant questions.
Let's continue with a few more answers:
Fruit is my third chess engine.
As I do for other projects (e.g. Othello), I start from scratch again every few years.
The code quality is much better than a single program improving over say 15 years.
I am french and live in Cambridge UK at the moment.
I feel like my citizenship is "european".
I might live in Italy in two years
Yes I believe I can improve Fruit easily for the next version.
See what I said about all the missing knowledge.
The source code will be made available on Dann's site when he gets up, you will be able to check for yourself.
He did not know I was going to release it open-source.
Oh, the name is Fruit of course, not Fruit_src; please rename it.
I will answer questions here, rather than trying to answer all in one go.
Bye for now, waiting for reactions.
Fabien.
---

I really do not understand.
I have king safety
I have mobility based on number of moves.
I thought they are important.
maybe the 3 or 4 boolean features that I do not have are important.
What do you mean that is all?
What about order of moves(maybe it is better than other engines?)
I am sure that it is possible to improve commercial programs and the results that I read suggest that commercial programs are extremely weak.
I did not test fruit against movei but based on reading Dann's post I got the impression that my movei is at similiar level to fruit and movei proved to be not without chances against commercial programs.
I guess that you have some advantages like better order of moves and better use of hash tables relative to me.
I am sure that the way that I use hash tables is extremely bad relative to other programs.

Uri,
It is very hard to answer you, because it looks like you think in a different way.
I think king safety and mobility are vital features.
My engine does not know about open files.
There is a single boolean feature for rooks: if there is a "own" pawn somewhere in front of it (same file) there is a negative bonus (malus?) for the rook.
Of course open files are more important!
Do you think I did not add them to give my program a handicap?
Of course not!
When I wrote my program a year ago, I was testing search features, such as checks in quiescence.
My goal was to study "chess trees", not to write a competition program.
You will see in the source code: there are files for mate searches (nothing like Chest mind you, more like "an engine without eval") or material-only searches, they are not used by the engine!
Because of that, Dann thought I was not using hash tables ))
I only added the minimum to the eval, to keep things somewhat simple.
Now I start testing the program and maybe it plays decent chess; I want to release "as is" anyway.
I am sure the following version will contain a "fairly normal" eval.
All I didn't describe is because it's the "normal" implementation, nothing special.
Move ordering is the "basic" trans-table move then MVV/LVA captures then 2 killers then history.
For more details wait for Dann to publish the source code please, I won't describe each line for you.
I am 100% sure there is nothing better than an average engine in there.
I think the difference is "design goal" and "consistency".
For example I want my search to be "stable". Many things I don't do like:
- updating alpha and beta when a hash hit does not cause a cutoff (notice this is only at PV nodes anyway).
- actually I don't ever cut-off at PV nodes!
"the PV must always be complete" is one of my design choices. The position at the end of the PV must evaluate to the search value or else I have a bug.
Not beta-cutting at PV nodes, that costs me I'm sure. Sometimes Fruit announces mate, but can't find it at the next move (but maybe the mate was imaginary then).
I think most engines don't have design goals, rather the author tries to improve this and that. I believe in consistency, if all of your engine-modules work together for a goal you can't go so very wrong?! I hope so anyway
About Movei; I can't test it of course I only have linux. I am convinced Movei is stronger. But please don't think "is Movei stronger?" "why is this engine better?" all day, we (programmers in general) have different engines that's all, let's celebrate that!
My hash tables are nothing special. Note depending of what Dann did, it only uses 16 MB, the UCI option does not affect hash table size in the code version that Dann has.
I do 4 probes, and always replace the shallowest entry.
I repeat; I did not describe the rest because it is IMO well-known "normal" implementation.
So in random order I use PVS, ETC, verified null move (not as described in the article, just normal null move then normal depth-reduced search without null move to check). Verification is only used in endgame.
Uri,
Although I have trouble understanding your posts (and not because of engline), I will try to answer your questions.
Bye for now,
Fabien.

Thanks
I will try to explain myself better.
1)I guess that one of the important things is implementing correctly the standard stuff.
I believe that a lot of engines with better evaluation are weaker than your fruit because they do not implement correctly the standard stuff.
2)I did not consider 4 probes in the hash tables as standard stuff and the same for ETC or verified null move pruning(I use verified null move pruning only in endgame and even in the endgame I only reduce the depth and do not do a research).
As far as I know they are not used by Crafty(I am not sure and it is possible that I simply got that wrong impression based on looking at the source code for not enough time) but maybe crafty is wrong by not using part of the standard stuff.
Uri

[Tord Romstad]

Geschrieben von: / Posted by: Tord Romstad at 10 March 2004 14:10:27:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 13:31:36:

Uri,
It is very hard to answer you, because it looks like you think in a different way.
I think king safety and mobility are vital features.
My engine does not know about open files.
There is a single boolean feature for rooks: if there is a "own" pawn somewhere in front of it (same file) there is a negative bonus (malus?) for the rook.
Of course open files are more important!

"Malus" is a cool word. Consider it stolen.
I don't have any kind of bonus for rooks on open or half-open files at the
moment. I've found that evaluating mobility is usually enough to make the engine
place its rooks on open files.
Tord

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 10 March 2004 14:17:56:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Tord Romstad at 10 March 2004 14:10:27:

Uri,
It is very hard to answer you, because it looks like you think in a different way.
I think king safety and mobility are vital features.
My engine does not know about open files.
There is a single boolean feature for rooks: if there is a "own" pawn somewhere in front of it (same file) there is a negative bonus (malus?) for the rook.
Of course open files are more important!

"Malus" is a cool word. Consider it stolen.
I don't have any kind of bonus for rooks on open or half-open files at the
moment. I've found that evaluating mobility is usually enough to make the engine
place its rooks on open files.
Tord

same for me.
I also do not have a special bonus for rook on open files and my mobility today is based only on number of legal of moves of both sides(no doubt that it can be improved but it is certainly better than nothing and I remember people who were impressed by the mobility of movei relative to other engines).
Uri

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 14:30:22:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Tord Romstad at 10 March 2004 14:10:27:

"Malus" is a cool word. Consider it stolen.
I don't have any kind of bonus for rooks on open or half-open files at the
moment. I've found that evaluating mobility is usually enough to make the engine
place its rooks on open files.
Tord

Malus is definitely used in French, don't know in English.
Yes I live in England and your English is better ))
Scandinavians are well known for speaking 5 languages fluently (even those they haven't learnt)
I don't have rooks on open files but as you know I don't have mobility either!
How this could lead to even remotely decent chess is a mystery to me.
Of course it doesn't; people only need time to notice.
Fabien.

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 10 March 2004 14:50:41:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Uri Blass at 10 March 2004 14:09:05:


Uri,
You are perfectly right!!!
I "had to" answer in a hurry, and I couldn't be 100% accurate.

Thanks
I will try to explain myself better.
1)I guess that one of the important things is implementing correctly the standard stuff.
I believe that a lot of engines with better evaluation are weaker than your fruit because they do not implement correctly the standard stuff.
2)I did not consider 4 probes in the hash tables as standard stuff and the same for ETC or verified null move pruning(I use verified null move pruning only in endgame and even in the endgame I only reduce the depth and do not do a research).
As far as I know they are not used by Crafty(I am not sure and it is possible that I simply got that wrong impression based on looking at the source code for not enough time) but maybe crafty is wrong by not using part of the standard stuff.

I 100% agree here. I noticed that while working on my previous engine. Nothing special at all, just a lot of code testing. Not chess games, just testing the code. Then I realised what you've just said. I can only conclude that many "average amateur" engines are buggy and it hurts their results.
But as of now Fruit is completely untested so there should be bugs in there, but I don't want to postpone the release too much (also that's why I don't want to add code now). I only want to fix the most dreaful bugs (if any) like not responding engine, eating opponent cpu time, or playing illegal moves. Losing on time in very short time control is acceptable for now, I don't have a high interest in bullet games anyway.
Again you are absolutely right!
Bob probably discarded them based on testing though. I think the trick here is that Crafty code is used a lot as a basis (not as basic of course, but starting point). But most of Bob's work is hidden, it's what he tested and discarded and we can't see that. Also people forget Bob's own "design goals". When one reads his comments in main.c one understands better.
About the features again, if one reads CCC a lot, they are quite well known. I think many private engine use some form of verification; we just don't see the source code. Also, do you really believe they can bring 100 elo points?
Again Fruit is untested, I did not base my choices on tests but on design goals. I want fruit to be OK for long searches, and I think for those 4 probes help branching factor (when the hash table gets saturated). I write "engines" for other games, and I always used at least 4 probes (8 is probably better for slow searchers).
Fabien.

[Ciro Vignotto]

Geschrieben von: / Posted by: Ciro Vignotto at 10 March 2004 15:15:34:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 14:30:22:

"Malus" is a cool word. Consider it stolen.
I don't have any kind of bonus for rooks on open or half-open files at the
moment. I've found that evaluating mobility is usually enough to make the engine
place its rooks on open files.
Tord

Malus is definitely used in French, don't know in English.

'bonus' and 'malus' are both Latin words, therefore if you used one you may also use the other.
Greetings, Ciro

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 10 March 2004 15:41:35:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Fabien Letouzey at 10 March 2004 14:50:41:

Uri,
You are perfectly right!!!
I "had to" answer in a hurry, and I couldn't be 100% accurate.

Thanks
I will try to explain myself better.
1)I guess that one of the important things is implementing correctly the standard stuff.
I believe that a lot of engines with better evaluation are weaker than your fruit because they do not implement correctly the standard stuff.
2)I did not consider 4 probes in the hash tables as standard stuff and the same for ETC or verified null move pruning(I use verified null move pruning only in endgame and even in the endgame I only reduce the depth and do not do a research).
As far as I know they are not used by Crafty(I am not sure and it is possible that I simply got that wrong impression based on looking at the source code for not enough time) but maybe crafty is wrong by not using part of the standard stuff.

I 100% agree here. I noticed that while working on my previous engine. Nothing special at all, just a lot of code testing. Not chess games, just testing the code. Then I realised what you've just said. I can only conclude that many "average amateur" engines are buggy and it hurts their results.
But as of now Fruit is completely untested so there should be bugs in there, but I don't want to postpone the release too much (also that's why I don't want to add code now). I only want to fix the most dreaful bugs (if any) like not responding engine, eating opponent cpu time, or playing illegal moves. Losing on time in very short time control is acceptable for now, I don't have a high interest in bullet games anyway.
Again you are absolutely right!
Bob probably discarded them based on testing though. I think the trick here is that Crafty code is used a lot as a basis (not as basic of course, but starting point). But most of Bob's work is hidden, it's what he tested and discarded and we can't see that. Also people forget Bob's own "design goals". When one reads his comments in main.c one understands better.
About the features again, if one reads CCC a lot, they are quite well known. I think many private engine use some form of verification; we just don't see the source code. Also, do you really believe they can bring 100 elo points?
Again Fruit is untested, I did not base my choices on tests but on design goals. I want fruit to be OK for long searches, and I think for those 4 probes help branching factor (when the hash table gets saturated).

I hope that you will give some information about the code that you used for testing.
I mainly used test position and games for testing and I am surprised that you talk about not using chess games.
There was time that I did not use chess game when I tested my move generator and I used the perft function but this time is over.
I am also interested in long time control but I do not have special bad branching factor at long time control and I believe better order of moves can help me.
As I wrote my hash tables are today extremely poor.
I do not use ETC and I do not use hash for pruning and I do not use hash to store moves and score except fail high and I also consider my order of moves as poor.
Inspite of it for some reason I do not see based on results that movei has special problems at long time control relative to other engine.

Uri

[Ulrich Tuerke]

Geschrieben von: / Posted by: Ulrich Tuerke at 10 March 2004 15:54:37:
Als Antwort auf: / In reply to: Re: info about Fruit geschrieben von: / posted by: Uri Blass at 10 March 2004 12:55:09:

Hello,
My first (technically second) post on the Winboard forum.
This is about my new engine Fruit.
Good thing that Dann released a version yesterday, I gain half a day then.
Sorry it is UCI only at the moment. I use xboard on linux and have my own "UCI2WB" adapter. I will see later with Dann Corbit if we manage to port it to Windows.
I will make sure Winboard users have some way of running my engine. If all fails, I will add Winboard support to the code, although this is against my design goals (code quality).
Fruit as of now is a completely untested engine that I wrote a year ago.
It has slept on my hard disk since then.
Suddenly I get motivated again by seeing tournaments beeing ran on the Internet e.g. WBEC.
I thought I would enjoy beeing part of that, but there is a long way to go ...
First step was to release my engine "as is" (as it was last year).
So I can start improving it (modifying a lot of code), without having to worry about when to release a stable version.
In short I'm not sure about what the code does anymore, I will have to reread the code!
I intend to change a lot of (small) things in the few months to come and that will introduce new bugs.
At least there will be a stable release to compare it to (should be next week if testing is OK).
It is true that I claim my engine is weak, because I know all that's missing from the code (few examples below).
But it is a completely untested engine, maybe it is good, I just don't expect it to be.
Example, what's in the eval:
- piece-square table
- static pawn eval (only basic pawn types, no interaction with pieces)
- 3 or 4 boolean features like "if there an "own pawn" along my "forward" bishop diagonals" (negative score)
That's all!!!
No king safety, no mobility of any kind, no connected passers, *no knowledge of drawish endgames*!
How could such a program play decent chess I do not know, it's not even fast.
Search:
R=3 nullmove, extend all check evasions 1 ply, try all checks 1st ply of quiescence.
That's all!!!
No other extension.
No parameter tuned, nothing tested!
After the release I will test several combinations of search parameter.
If I have time next week-end I will add them as UCI options so people can play with it.
In commercial programs they are already tuned so you can't improve the program.

I really do not understand.
I have king safety
I have mobility based on number of moves.
I thought they are important.
maybe the 3 or 4 boolean features that I do not have are important.
What do you mean that is all?
What about order of moves(maybe it is better than other engines?)
I am sure that it is possible to improve commercial programs and the results that I read suggest that commercial programs are extremely weak.
I did not test fruit against movei but based on reading Dann's post I got the impression that my movei is at similiar level to fruit and movei proved to be not without chances against commercial programs.
I guess that you have some advantages like better order of moves and better use of hash tables relative to me.
I am sure that the way that I use hash tables is extremely bad relative to other programs.

Uri

It's often surprising how little chess knowledge is necessary in order to create a reasonable play.
A long time ago, I had had a look into the code of Bruce's Gerbil, which already plays fairly well imho. When looking at the evaluation code, I found before it really started, what had puzzled me a lot.
In case, I would have the idea to write a new program, I would think much more about any piece of evaluation code before implementing; basic rule: the lesser the better, in case of doubt regarding usefulness of the code I'd rather skip it.
Uli