
Legal details
-------------

Fruit 1.5 Copyright 2004 Fabien Letouzey.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA

See the file "COPYING" for details.


General
-------

Today is 2004/06/04.  This is Fruit 1.5 (Strawberry).

Fruit is a UCI-only chess engine.  This distribution comes up with
Windows/Linux/MacOS executable files and platform-independent source
code.

Sorry that the word "Fruit" looks like "Fritz" (it certainly sounds
different in English).  This is obviously unintentional (or is it not,
yes?  I don't know anymore)!

PS: how would "Deep Fruit" sound? :)


Official distribution URL
-------------------------

The official distribution web site is Leo Dijksman's WBEC Ridderkerk:
http://wbec-ridderkerk.nl/  This is where you should be looking for
Fruit updates in the future.


Version
-------

Now I can already hear this from the future:
"1.0 -> 1.5, can he count at all?"

Hehe you won't get me so easily, I am prepared for that one.

I noticed classical software version numbers cannot be easily applied
to chess engines ...  I originally planned for a version 1.1 which
would see a large number of changes applied to Fruit 1.0.  I quickly
decided that those changes would justify a switching to a (non-
existant-as-of-now) version 2.0.

I got very lucky and the first changes (e.g. addition of mobility)
made Fruit noticeably stronger.  At some point during the development
I opted for an "early" release before I carry on with the rest of the
plan.  Because I am roughly halfway through these changes (at least in
UK Imperial-System measurement), I decided for a current version 1.5
(got it?  It's funny, right?).


Files
-----

The file TECHNICAL_10 only concerns the older version 1.0 of Fruit
(because I am too lazy to edit it right now).  Most of it is still
valid for Fruit 1.5 because the main changes affect only the
evaluation function (see History).


Compiling
---------

Fruit was developed on Linux using g++ (the GNU C++ compiler).

The source code has also been successfully compiled on Windows using
both MSVC and Intel C++ compilers.  Minor problems have been reported
on MacOS X (problems in the system header files; a work-around
involving changing the order of #include directives in Fruit's source
code was used).  I do not know about FreeBSD/OpenBSD/NetBSD or other
POSIX-compliant operating systems, but I don't expect many problems.

If you had problems getting Fruit compiled on your system, but somehow
managed it in the end, please let me know what changes were necessary
(see the contact section for details).

At the very least, you should use the "-O2" option.
> g++ -O2 -o fruit *.cpp

These are the options I use:
> g++ -O2 -fomit-frame-pointer -fstrict-aliasing -fno-exceptions -fno-rtti -o fruit *.cpp
You will also want to add a suitable CPU option, for example
"-mcpu=athlon-xp".

If you know better options for g++ please let me know.  I will add a
benchmark feature in the future so that speed can be tested from the
command line.


Design goals
------------

Many design choices in Fruit were affected by "design goals" I had
chosen before writing the code.

For instance, I try to reduce the code size and prevent Fruit from
using more memory than is necessary (tables whose size can be
arbitrarily reduced such as the transposition table do not count).  I
intend to spend a lot of effort on this aspect for the next versions
of Fruit (for example by removing code that is not needed, and
reducing stack-size requirements).  Note here that I do not have
special plans to port Fruit onto PDAs, although this should be rather
easy (in the future!) for 32-bit platforms (but 16-bit ones are dying
anyway).

About the playing style, I would like Fruit to play positional games
focusing mainly on active placement of pieces and pawn structure
defects.  It is however possible that playing style becomes a
selectable option in the future, as long as little extra code is
needed (for example by giving large bonuses to advanced pieces, making
Fruit less passive).

Note that for this strategy to be consistent, a lot of endgame
knowledge will need to be added to the program (oops, not
fascinating).


XBoard / Winboard
-----------------

Fruit is a UCI-only engine.  This is unlikely to change in the future.

Fruit and other UCI engines can be used with XBoard or WinBoard (or
other xboard-compatible interfaces) with the help of PolyGlot
(UCI-to-xboard adapter).  You can download PolyGlot at
http://wbec-ridderkerk.nl/index.html


Opening book
------------

Fruit comes without an opening book.  There is no short-term plan to
include one.  I consider Fruit as a toy rather than a competition
engine.  You are welcome to provide it with any book of your choice.


Tablebases
----------

Fruit does not use the so-called Nalimov tablebases, sorry for that.
This is unlikely to change in the future.

The reasons for my decision are:

- the source code by Eugene Nalimov is not "free of use" (although you
  don't have to pay for it)

- the design of the code does not work well with Fruit's "small memory
  footprint" requirement (for example the executable file would be at
  least twice as large with the TB code).

It must be said though that I have great respect for Eugene's
contribution to the computer-chess community.

As for Fruit I plan on using selected "bitbases" in the (very far) future.


UCI options
-----------

You are advised to skip this section unless you are completely crazy
about computer chess.

Here I give you another chance to skip the section, as you should not
be reading this ...

- "Log" (true/false, default: false)

Use a log file?  This is not very useful in this version because fruit
only "logs" the UCI traffic, not internal events.

- "LogFile" (string, default: fruit.log)

The name of the file.

- "Enhanced Transposition Cutoff" (true/false, default: true)

Makes the transposition table more effective near the endgame, at the
cost of speed.  Note that Fruit uses this heuristic only far away from
the leaves and the speed drop should not be consequent.

- "NullMove" ("Always"/"Fail High"/"Never", default: "Fail High")

"Always" actually means the usual conditions (not in check, etc ...).
"Fail High" adds the condition that the static evaluation fails high.
Never use "Never" (ever)!

I expect that this option has little effect (assuming the first two
choices only).  I only added it because most engines do not use the
fail-high condition.

Independently of this option, verification search is used in the
endgame.

- "NullMove Reduction" (1-3 plies, default: 3)

3 is rather aggressive, especially in the endgame.  It is possible
that 2 leads to safer play.

- "SingleReply Extension" (true/false, default: true)

Another common extension.  Extend one ply if there is only one legal
move to get out of check.  Deactivating it would make Fruit search
deeper overall, but the lack of king-safety evaluation might make this
change a risky one.

- "PawnPush Extension" (true/false, default: false)

A common extension in other engines (extend pawns pushes to 7th rank).
Activating it could make Fruit stronger in the endgame.

- "Checks in Quiescence" ("Always"/"After NullMove"/"Never", default:
"Always")

Note that Fruit only tries checks at the first ply of the quiescence
in this version.  "Always" was selected as the default because it
seemed like the "safe bet".  "After NullMove" might be a better
choice.  I also recommend against using "Never" here, because Fruit
has few tactical extensions, and no mate-threat detection.

- material options

You can modify the basic value of pieces (and the additional bonus for
the bishop pair) in centi-pawns.  Each option consists of two values
for the opening and endgame phase.  Fruit interpolates between the two
values for intermediate phases.


History
-------

Fruit was written in early 2003, then hibernated for many months.  I
suddenly decided to remove some dust from it and release it after
seeing the great WBEC web site by Leo Dijksman!  Note that Fruit is
nowhere near ready to compete there because of the lack of xboard
support and opening book.


2004/03/17 Fruit 1.0, first stable release
------------------------------------------

Fruit 1.0 is as close to the original program as possible, with the
main exception of added UCI-handling code (Fruit was using a private
protocol before).  It is a very incomplete program, released "as is",
before I start heavily modifying the code (for good or bad).

You can find a succinct description of some algorithms that Fruit uses
in the file "TECHNICAL_10" (don't expect much).


2004/06/04 Fruit 1.5, halfway through the code cleanup
------------------------------------------------------

- added mobility in evaluation (makes Fruit play more actively)

- added drawish-material heuristics (makes Fruit look a bit less stupid
  in some dead-draw endgames)

- tweaked the piece/square tables (especially for knights)

- added time management (play easy moves more quickly, take more time
  when unsure)

- enabled the single-reply extension (to partly compensate for the lack
  of king safety)

- some speed up (but bear in mind mobility is a costly feature, when
  implemented in a straightforward way as I did)


Future?
-------

I am so lazy that I will answer my own predictions when releasing
Fruit 1.0 (mail-reply style):

> The future of Fruit is very uncertain.

Oh well here we are in the future, and Fruit is updated!  It's clearly
easier to predict the future when it's passed, so that's nothing to
brag about.

> I plan to release a cleaned-up version 1.1 (no idea when though), with
> all unused/useless code removed (I want to remove some "optimised"
> code that makes Fruit much larger than it should be).  This will most
> likely result in a small speed drop, but I hope that this will be more
> than compensated by the addition of some new features as described
> below.

Hm ... let's say that around half of this has been done.  The version
number 1.5 indicates that I have hopes for a version 2.0 onces these
changes are completed!

> Fruit has so little chess knowledge that I hope a few "simple"
> enhancements are going to improve the strength although nothing
> spectacular is expected.  My general procedure will most likely be
> watching Fruit playing games, and trying to recognise general mistake
> "patterns" (I have already noticed a few).  I am talking about the
> evaluation function here; if Fruit gets consistently outsearched I
> will conclude that the opponent is too strong and move on to something
> more productive (Pepito comes to mind for some reason) :)

Some knowledge has been added (mobility to simulate piece activity,
awareness of a few drawish endgames, better time usage).  The other
statements are still valid!

> Priorities will include adding:

> - basic knowledge about drawn (also drawish?) endgames

Done.

> - a bit of "material tuning", like "2 minors > R+P" or "don't exchange
>   pieces when behind"

Not done, the problem is still visible.  Using larger material values
for all pieces (but not pawns) would probably fix it.

> - selected features (depending on experimental results); for example
>   "bad bishops", "rooks on open files", "doubled rooks on 7th ranks" or
>   "connected passed pawns" (yes, Fruit has none of those!).

Hm ... it still doesn't have any of those :)  Let me even add "king
safety" to the list!!!  That means I considered it as so unimportant
that it wasn't even worth mentionning, this shows a lot about my
computer-chess understanding :)

> - a "smart" time management such as spending less time on "obvious"
>   moves and more time when the score drops for instance

Oh, that's done!

> In the long term, I intend to work on the pawn-evaluation code.

Change that to "short term" now.

> I will also try to prevent Fruit from becoming too similar to other
> engines.  This means that I will want to keep features even if they
> hurt Fruit's results, as they would give Fruit a "personality".

I'd like to but it's not so easy!  Let's say I don't want Fruit to
become a king attacker :)  Well it does not use bitboards so it's
already different, right?  It's not the same OK?  Right?

> I hope that I will be able to use original (as in "not too common")
> ideas in move ordering and the quiescence search, although I can't be
> optimistic.

Yes, yes!  After the evaluation-function rewriting is finished though
(so that will probably be after version 2.0).


Known bugs
----------

The following are all problems in the UCI-handling code
(like there's no bugs in the engine /Ed):

The hash-table size can only be set at startup time (when Fruit is
loaded into the interface).  Fruit will ignore any subsequent requests
to change the size.  This is a bug due to my own laziness and not a
lame attempt to counter cripple-chess variants popular in some
interfaces.

Fruit always claims that CPU is 100% used.  This is apparently a
problem in the standard C libraries on Windows.  Mailbomb me if fixing
this would save lives (especially children)!

The UCI "searchmoves" option of the "go" commands is not supported at
all.  I do not know when this option is used by interfaces but I think
it is only in special circumstances such as "find the second-best
move".

^^^
Anybody cares about this???


Thanks
------

Big thanks go to:

- Joachim Rang for spending so much time testing different
  versions/settings of Fruit and getting actively involved in the
  project in general

- Dann Corbit and Slater Wold for spending a lot of time compiling
  Fruit (including development versions) for Windows and
  testing, giving improvement ideas (common, you can do it with all
  the source code you've seen ;) ), etc ...

- Tord Romstad and Joshua Shriver for compiling for MacOS X

- Leo Dijksman for hosting the Fruit distribution (and also the
  PolyGlot adapter) on his web site (see Links)

- Aaron Gordon for his help in the past and in the future ...

Of course a "thanks" section is never complete, as for instance I
received a lot of help from CCC users (mostly via the search engine).
Also the cheerings on the WinBoard forum are a necessary fuel to keep
the programmers going!

Links
-----

- engine lists and much more:

Leo Dijksman's WBEC Ridderkerk: http://wbec-ridderkerk.nl/
Alex Schmidt's UCIengines.de: http://www.uciengines.de/

- free chess GUIs:

Tim Mann's Chess Pages: http://www.tim-mann.org/xboard.html
Frank Quisinsky's Chess Page: http://www.amateurschach.de/_menue.htm

- computer-chess forums:

The Computer Chess Club (CCC): http://www.talkchess.com/
Volker Pittlik's Winboard Forum: http://f11.parsimony.net/forum16635/

- mostly programmer stuff (if you have several lives to spend):

Dann Corbit's FTP: ftp://cap.connx.com (do *not* use passive mode)

Sorry for the dozens I simply had to leave away (but you know them if
you went that far) ...


Contact me
----------

My name is Fabien Letouzey.  I am a 32-year-old frenchman, and live in
Cambridge UK at the moment.  Fruit is not my first chess engine, and I
also write programs for Othello, international draughts and recently
Awari.

You can contact me at fabien_letouzey@hotmail.com

Especially welcome are (not necessarily in order of importance):

- "Fruit Fan Club" T-shirts (which, rather surprisingly, seem hard to
  find at the moment).  Update: if you're smart don't put the version
  number on the T-shirt, thanks!

- additional source code that give 500 extra Elo points (one liners
  preferred).  My mailbox is sometimes full, so don't hesitate to send
  it again because I haven't found it, so ...

- Arena for Linux (without emulator)

Especially not welcome are reports of matches against Shredder that
Fruit lost 1000-0.


The end
-------

Thanks for listening, and have fun with Fruit!

Fabien Letouzey, 2004/06/04.

