5 Fruit 2.1 Copyright 2004-2005 Fabien Letouzey.
\r
7 This program is free software; you can redistribute it and/or modify
\r
8 it under the terms of the GNU General Public License as published by
\r
9 the Free Software Foundation; either version 2 of the License, or (at
\r
10 your option) any later version.
\r
12 This program is distributed in the hope that it will be useful, but
\r
13 WITHOUT ANY WARRANTY; without even the implied warranty of
\r
14 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
\r
15 General Public License for more details.
\r
17 You should have received a copy of the GNU General Public License
\r
18 along with this program; if not, write to the Free Software
\r
19 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
\r
22 See the file "copying.txt" for details.
\r
28 Today is 2005/06/17. This is Fruit 2.1 (Peach).
\r
30 Fruit is a UCI-only chess engine. This distribution comes up with
\r
31 Windows, Linux and Mac OS X executable files as well as an opening
\r
32 book and platform-independent source code.
\r
34 Sorry that the word "Fruit" looks like "Fritz" (it certainly sounds
\r
35 different in English). This is obviously unintentional (or is it not,
\r
36 yes? I don't know anymore)!
\r
38 PS: How would "Deep Fruit" sound? :)
\r
41 Official distribution URL
\r
42 -------------------------
\r
44 The official distribution web site is Leo Dijksman's WBEC Ridderkerk:
\r
45 http://wbec-ridderkerk.nl/ This is where you should be looking for
\r
46 Fruit updates in the future.
\r
52 "2.1, what's with the version number? I invested $1M on 2.5 at the
\r
53 stock market and now who's gonna bring my money back???"
\r
55 Not me! Version numbers have nothing to do with chess strength, but
\r
56 with the quantity of code change and the position of the program in
\r
59 I decided to enter the Massy tournament (2005/06/12) only two weeks
\r
60 beforehand, and I had to quickly decide for the version that would
\r
61 play. There were only 3 main changes as compared with Fruit 2.0,
\r
62 because I had also been working on other programming projects.
\r
64 After the tournament, "Fruit Massy" was tested and it appeared obvious
\r
65 that some strength had been gained. Fruit 2.1 is a "hurry release" of
\r
66 the tournament version. It took a few more days to fix an interface
\r
67 problem (hash-table size under Arena) and add opening-book code
\r
68 (compatible with PolyGlot).
\r
70 OK so in short I switched from 2.0 to 2.1 because there were few
\r
71 changes and I don't especially have plans for a 3.0, sorry for that.
\r
73 For a description of the main additions, see the History section.
\r
79 The archive contains executable files for Windows, Linux and Mac OS X,
\r
80 as well as source code and a small opening book.
\r
82 The file "technical_10.txt" only concerns the - obsolete - version 1.0
\r
83 of Fruit (because I am too lazy to edit it right now AND also was when
\r
84 releasing Fruit 2.0 AND also ...). The search part of it is still
\r
85 valid for Fruit 2.1 (except for the addition of history pruning).
\r
86 However the evaluation function has almost been completely re-written.
\r
87 Again, see the History section for a succinct description.
\r
93 The distribution comes up with Windows, Linux and Mac OS X binaries.
\r
94 Compiling is therefore not necessary on those systems unless you want
\r
95 to make a change in the program. In any case this section describes
\r
96 the compiling procedure, it is safe to skip it.
\r
98 Fruit was developed on Linux using g++ (the GNU C++ compiler).
\r
100 The source code has also been successfully compiled on Windows using
\r
101 both MSVC and Intel C++ compilers. I do not know about
\r
102 FreeBSD/OpenBSD/NetBSD or other POSIX-compliant operating systems, but
\r
103 I don't expect many problems.
\r
105 If you had problems getting Fruit compiled on your system, but somehow
\r
106 managed it in the end, please let me know what changes were necessary
\r
107 (see the contact section for details).
\r
109 I have now included my Makefile for Unix systems. It is a bit weird
\r
110 (it uses GNU extensions), I hope it works on your OS (let me know if
\r
111 it doesn't). Associate the "-march" option with the appropriate
\r
112 value on your system, and type "make" in the "src" directory.
\r
114 If you find better optimisation options for g++ please let me know.
\r
120 Fruit is a UCI-only engine. This is unlikely to change in the future.
\r
122 Fruit and other UCI engines can be used with XBoard or WinBoard (or
\r
123 other xboard-compatible interfaces) with the help of PolyGlot
\r
124 (UCI-to-xboard adapter). You can download PolyGlot at
\r
125 http://wbec-ridderkerk.nl/
\r
133 Starting with version 2.1, Fruit handles an opening book,
\r
134 tada! (<- Windows 3.x sound for those old enough to remember).
\r
136 I cloned the code from my own software (assuming it was legal)
\r
137 "PolyGlot", sorry myself (it's OK /Ed). And some say that open-source
\r
140 Now, I hear it already. Tournament directors will want me to
\r
141 designate an official book that they should use. To keep download
\r
142 overhead low, I decided to include only a small book in the main
\r
143 archive: it's called "book_small.bin". It is in fact the same as
\r
144 "fruit.bin" in the PolyGlot 1.3 release.
\r
146 However, I would prefer that Fruit has access to a larger book during
\r
147 tournaments. At the time I am writing this line, "book_corbit.bin" is
\r
148 planned to be made available on WBEC.
\r
150 You can build your own book from a PGN file by using PolyGlot on the
\r
151 command line. PolyGlot is available for download at
\r
152 http://wbec-ridderkerk.nl/
\r
158 Fruit does not use the so-called Nalimov tablebases, sorry for that.
\r
159 This is unlikely to change in the future.
\r
161 The reasons for my decision are:
\r
163 - the source code by Eugene Nalimov is not "free of use"
\r
164 (although you don't have to pay for it)
\r
166 - the design of the code does not work well with Fruit's "small memory
\r
167 footprint" requirement (for example the executable file would be at
\r
168 least twice as large with the TB code).
\r
170 It must be said though that I have great respect for Eugene's
\r
171 contribution to the computer-chess community.
\r
173 As for Fruit I plan on using selected "bitbases" in the (very far)
\r
174 future. For now some draws are recognised by the evaluation function,
\r
175 and - despite the errors - this somewhat reduces the penalty for not
\r
182 You are advised to skip this section unless you are completely crazy
\r
183 about computer chess.
\r
185 Here I give you another chance to skip the section, as you should not
\r
186 be reading this ...
\r
188 Well you have downloaded Fruit in the first place so I suppose I can't
\r
189 do anything for you anyway ... I give up!
\r
191 - "NullMove Pruning" (Always/Fail High/Never, default: Fail High)
\r
193 "Always" actually means the usual conditions (not in check, etc ...).
\r
194 "Fail High" adds the condition that the static evaluation fails high.
\r
195 Never use "Never" (ever)! OK you can use "Never" to test a Zugzwang
\r
196 problem, but ask your Momma first!
\r
198 I expect that this option has little effect (assuming the first two
\r
199 choices only). I only added it because most engines do not use the
\r
200 fail-high condition.
\r
202 - "NullMove Reduction" (1-3 plies, default: 3)
\r
204 3 is rather aggressive, especially in the endgame. It seems better
\r
205 than always using 2 though. I have not experimented with adaptive
\r
208 - "Verification Search" (Always/Endgame/Never, default: Endgame)
\r
210 This tries to solve some Zugzwang-related problems. I expect it to
\r
211 hardly have any effect in games. The default value should be
\r
212 sufficient for most-common Zugzwang situations.
\r
214 - "Verification Reduction" (1-6 plies, default: 5)
\r
216 5 guarantees that the cost of verification search is negligible in
\r
217 most cases. Of course it means Zugzwang problems need a lot of depth
\r
218 to get solved, if ever! With such a reduction, verification search is
\r
219 similar to Vincent Diepeveen's "double null move".
\r
221 - "History Pruning" (true/false, default: true)
\r
223 A bit dodgy, but fun to experiment with. I added it in Fruit 2.0, and
\r
224 I still haven't found the time to test it seriously ... It should
\r
225 help in blitz, but it's possible it actually hurts play in longer
\r
226 games(!!!). One day, I should check this. One day ...
\r
228 - "History Threshold" (percentage, default: 60%)
\r
230 This is the thing, as it affects the search tree! Lower values are
\r
231 safer, and higher values more aggressive. THIS VALUE HAS NOT BEEN
\r
232 TUNED! There is a good chance Fruit's strength can be improved by
\r
233 changing this option.
\r
235 - "Futility Pruning" (true/false, default: false)
\r
237 Very common but controversial. Makes the engine a tiny bit
\r
238 better at tactics but slightly weaker positionally. It might be
\r
239 beneficial by a very small amount, but has not been tested in
\r
240 conjunction with history pruning yet.
\r
242 - "Futility Margin" (centipawns, default: 100)
\r
244 This value is somewhat aggressive. It could lead to problems in
\r
245 the endgame. Larger values prune less but will lead to fewer
\r
248 - "Delta Pruning" (true/false, default: false)
\r
250 Similar to futility pruning. Probably safer because it is used
\r
251 mainly during the middlegame. Has not been tested with history
\r
254 - "Delta Margin" (centipawns, default: 50)
\r
256 Same behaviour as futility margin. This one is probably safe.
\r
258 - "Quiescence Check Plies" (0-2 plies, default: 1)
\r
260 Fruit tries safe (SEE >= 0) checks at the first plies of the
\r
261 quiescence search. 0 means no checks at all (as in most older
\r
262 engines). 1 is the same as previous versions of Fruit. 2 is probably
\r
263 not worth the extra cost. It could be interesting when solving mate
\r
266 - evaluation options (percentage, default: 100%)
\r
268 These options are evaluation-feature multipliers. You can modify
\r
269 Fruit's playing style to an extent or make Fruit weaker for instance
\r
270 by setting "Material" to a low value.
\r
272 "Material" is obvious. It also includes the bishop-pair bonus.
\r
273 "Piece Activity": piece placement and mobility.
\r
274 "King Safety": mixed features related to the king during early phases
\r
275 "Pawn Structure": all pawn-only features (not passed pawns).
\r
276 "Passed Pawns": ... can you guess?
\r
278 I think "Pawn Structure" is not an important parameter.
\r
279 Who knows what you can obtain by playing with others?
\r
285 2004/03/17 Fruit 1.0, first stable release
\r
286 ------------------------------------------
\r
288 Fruit was written in early 2003, then hibernated for many months.
\r
289 I suddenly decided to remove some dust from it and release it after
\r
290 seeing the great WBEC web site by Leo Dijksman! Note that Fruit is
\r
291 nowhere near ready to compete there because of the lack of xboard
\r
292 support and opening book. Note from the future: these limitations
\r
293 seem not to be a problem anymore.
\r
295 Fruit 1.0 is as close to the original program as possible, with the
\r
296 main exception of added UCI-handling code (Fruit was using a private
\r
297 protocol before). It is a very incomplete program, released "as is",
\r
298 before I start heavily modifying the code (for good or bad).
\r
300 You can find a succinct description of some algorithms that Fruit uses
\r
301 in the file "technical_10.txt" (don't expect much).
\r
304 2004/06/04 Fruit 1.5, halfway through the code cleanup
\r
305 ------------------------------------------------------
\r
307 In chronological order:
\r
309 - added mobility in evaluation (makes Fruit play more actively)
\r
311 - added drawish-material heuristics (makes Fruit look a bit less stupid
\r
312 in some dead-draw endgames)
\r
314 - tweaked the piece/square tables (especially for knights)
\r
316 - added time management (play easy moves more quickly, take more time
\r
319 - enabled the single-reply extension (to partly compensate for the lack
\r
322 - some speed up (but bear in mind mobility is a costly feature, when
\r
323 implemented in a straightforward way as I did)
\r
326 2004/12/24 Fruit 2.0, the new departure
\r
327 ---------------------------------------
\r
329 The main characteristic of Fruit 2.0 is the "completion" of the
\r
330 evaluation function (addition of previously-missing major features).
\r
332 In chronological order:
\r
334 - separated passed-pawn evaluation from the pawn hash table,
\r
335 interaction with pieces can now be taken into account
\r
337 - added a pawn-shelter penalty; with king placement this forms
\r
338 some sort of a simplistic king-safety feature
\r
340 - added incremental move generation (Fruit was starting to be too slow
\r
343 - added futility and delta pruning (not tested in conjunction with
\r
344 history pruning and hence not activated by default)
\r
346 - improved move ordering (bad captures are now postponed)
\r
348 - added history pruning (not tested seriously at the time I write
\r
349 this yet enabled by default, I must be really dumb)
\r
351 - cleaned up a large amount of code (IMO anyway), this should allow
\r
352 easier development in the future
\r
355 2005/06/17 Fruit 2.1, the unexpected
\r
356 ------------------------------------
\r
358 Unexpected because participation in the Massy tournament had not been
\r
359 planned. What you see is a picture of Fruit right in the middle of
\r
360 development. There may even be bugs (but this is a rumour)!
\r
362 I have completed the eval "even more", not that it's ever complete
\r
363 anyway. I have to admit that I had always been too lazy to include
\r
364 king attacks in previous versions. However, some programs had fun
\r
365 trashing Fruit 2.0 mercilessly in 20 moves, no doubt in order to make
\r
366 me angry. Now they should need at least 25 moves, don't bother me
\r
369 - added rook-on-open file bonus; thanks to Vincent Diepeveen for
\r
370 reminding me to add this. Some games look less pathetic now.
\r
372 - added pawn storms; they don't increase strength but they are so
\r
373 ridiculous that I was unable to deactivate them afterwards!
\r
375 - added PV-node extensions (this is from Toga), e.g. extending
\r
376 recaptures only at PV nodes. Not sure if these extensions help; if
\r
377 they do, we all need to recognise Thomas Gaksch's contribution to
\r
380 - added (small) king-attack bonus, the last *huge* hole in the eval;
\r
381 now only large holes remain, "be prepared" says he (to himself)!
\r
383 - added history-pruning re-search; does not help in my blitz tests,
\r
384 but might at longer time control; it's also safer in theory,
\r
385 everybody else is using it and I was feeling lonely not doing like
\r
386 them. OK, Tord told me that it helped in his programs ...
\r
388 - added opening book (compatible with PolyGlot 1.3 ".bin" files)
\r
390 - fixed hash-size UCI option, it should now be easy to configure using
\r
391 all interfaces (there used to be problems with Arena, entirely by my
\r
398 Why a breakpoint now? For the first time of its life, after the
\r
399 recent addition of king attacks, Fruit has all major (but admittedly
\r
400 few others) evaluation components. Don't get me wrong: they all need
\r
401 a lot of refinement, but the code layout is there.
\r
403 When Fruit 1.0 was released, some programmers told their surprise
\r
404 that the program was playing OK-ish (not that I agreed) despite having
\r
405 virtually no eval. They might have wondered whether their larger code
\r
408 Since then, I have mostly added classical evaluation features. I
\r
409 believe that Fruit has gained overall 150 to 200 Elo points by
\r
410 evaluation alone. Here I just want to explain that the minimalism of
\r
411 Fruit 1.0 was never a goal, but the consequence of the "as is" state
\r
412 of the distribution.
\r
414 In the end, the moral is safe: eval is good for you!
\r
415 Also "don't jump at conclusions" seems appropriate.
\r
421 Because of this "hurry release", I haven't had the time to continue
\r
422 cleaning up the code. This is the main reason why the version number
\r
425 I hope to provide a cleaner alternative, perhaps tuned a little, in a
\r
426 few months. Maybe it is time to consider adding features like
\r
429 Although I believe I could keep on increasing strength by adding more
\r
430 and more eval terms, I have little interest in doing so. I would not
\r
431 learn anything in the process, unless I develop new tuning/testing
\r
432 techniques. Ideally I would like to spend more time in alternative
\r
433 software, like my own GUI perhaps (specific to engine testing/matches).
\r
435 Nonetheless, a lot can be done like tuning existing code or building
\r
436 an adapted opening book. Therefore, don't hesitate to contact me if
\r
437 you are interested in giving a hand. Computer testing time is
\r
438 especially welcome, but be warned that I am quite demanding. "I can
\r
439 include test versions in my Fritz-GUI swiss tournament." -> forget it,
\r
440 as well as my email address please, thanks a lot!
\r
442 Lastly, don't take it too seriously. I am tired and always under big
\r
443 pressure before a release, because I want everything to go smoothly.
\r
444 Who knows what I will think in a month?
\r
450 Contrary to Fruit 2.0, Fruit 2.1 checks the legality of the hash-table
\r
451 move before playing it. This could make Fruit 2.0 crash in rare
\r
452 occasion (like once every 10000 games). This means that if Fruit 2.1
\r
453 crashes, the bug is somewhere else.
\r
455 Fruit 2.1 will now tolerate a hash-table resize after initialisation.
\r
456 This seems especially important for use with Arena. Unfortunately, it
\r
457 also raises the notorious 1MB problem of some "bug"-full interface ...
\r
463 Fruit always claims that CPU is 100% used. This is apparently a
\r
464 problem in the standard C libraries on Windows. Mailbomb me if fixing
\r
465 this would save lives (especially children)! I prefer waiting for
\r
466 late users to throw away Windows 95/98/ME before adding an
\r
467 NT/2000/XP/... solution.
\r
475 - Joachim Rang and Robert W. Allgeuer for spending so much time
\r
476 testing different versions/settings of Fruit and getting actively
\r
477 involved in the project in general. I don't know why they got
\r
478 interested in Fruit but the current version would definitely NOT
\r
479 exist without them.
\r
481 - Bryan Hofmann for compiling Fruit (and other engines) for Windows
\r
483 - Aaron Gordon for the Linux binary and long-term friendship;
\r
484 he's the one who showed me CCC years ago!
\r
486 - George Sobala for the Mac OS X executable
\r
488 - Leo Dijksman for hosting the Fruit distribution (and also the
\r
489 PolyGlot adapter) on his web site (see Links) and all the rest:
\r
490 tournament, testing, documentation, etc, ... For those who have not
\r
491 noticed (e.g. people still using a TRS-80), Leo is EXTREMELY serious
\r
492 in what he is doing. A reference in behaviour!
\r
494 - Ernest Bonnem for making it possible for Fruit to play in the
\r
495 Massy 2005 tournament
\r
497 - Tord Romstad for being my virtual twin brother; who knows if we can
\r
498 materialise in the same place some day?
\r
500 - You, for having patiently waited for this release and still being
\r
501 reading this file (don't worry, it's nearly finished)
\r
503 As usual there are dozens missing, it is simply impossible to include
\r
510 - engine lists, and much more:
\r
512 Leo Dijksman's WBEC Ridderkerk: http://wbec-ridderkerk.nl/
\r
513 Alex Schmidt's UCIengines.de: http://www.uciengines.de/
\r
517 Tim Mann's Chess Pages: http://www.tim-mann.org/xboard.html
\r
518 Arena: http://www.playwitharena.com/
\r
520 - computer-chess fora:
\r
522 The Computer Chess Club (CCC): http://www.talkchess.com/
\r
523 Volker Pittlik's Winboard Forum: http://wbforum.volker-pittlik.name/
\r
525 - mostly programmer stuff (if you have several lives to spend):
\r
527 Dann Corbit's FTP: ftp://cap.connx.com (do *not* use passive mode)
\r
529 Sorry for the dozens I simply had to leave away (but you know them if
\r
530 you went that far) ...
\r
536 You can contact me at fabien_letouzey@hotmail.com
\r
538 For a long time, I have been waiting in vain for the "Fruit Fan Club"
\r
539 T-shirts and donations of source-code improvements of several hundreds
\r
540 Elo points I had been asking for. About the latter I have to say that
\r
541 it is not very smart to delay much further: the more you wait and the
\r
542 more difficult it will be, but I suppose that it had not yet been
\r
543 challenging enough ...
\r
545 Anyway, I have decided to launch a new initiative. What's more boring
\r
546 than reading one's own code at 3am tracking down a bug that might not
\r
547 even exist, know what I mean? I have the solution: let's fix
\r
550 The new operation is called "Fix my Bugs and I Fix Yours!" (patent
\r
551 pending). It works as follows:
\r
553 1) You fix one of my bugs (excluding null move) before 2005/09/01
\r
554 00:00 UTC (the acronym that does not mean anything in either
\r
555 English or French, so that both parties are equally disappointed).
\r
557 2) I select the most artistic bug fix after the date limit. A jury
\r
558 will be nominated if necessary.
\r
560 3) I fix a bug of your choice in your program (excluding "it plays bad
\r
561 moves"), it's that simple!
\r
563 This is not irony: contrary to popular belief, there really are bugs
\r
564 in Fruit. Even search bugs. I just couldn't be bothered with fixing
\r
565 them so far. Sorry that I can't give you more hints, for now I am
\r
566 using them to find clones effortlessly.
\r
568 See you in September!!!
\r
574 Thanks for listening, and have fun with Fruit!
\r
576 Fabien Letouzey, 2005/06/17.
\r
projects / xboard.git / blob