+++ /dev/null
-\r
-Legal details\r
--------------\r
-\r
-Fruit 2.1 Copyright 2004-2005 Fabien Letouzey.\r
-\r
-This program is free software; you can redistribute it and/or modify\r
-it under the terms of the GNU General Public License as published by\r
-the Free Software Foundation; either version 2 of the License, or (at\r
-your option) any later version.\r
-\r
-This program is distributed in the hope that it will be useful, but\r
-WITHOUT ANY WARRANTY; without even the implied warranty of\r
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\r
-General Public License for more details.\r
-\r
-You should have received a copy of the GNU General Public License\r
-along with this program; if not, write to the Free Software\r
-Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307\r
-USA\r
-\r
-See the file "copying.txt" for details.\r
-\r
-\r
-General\r
--------\r
-\r
-Today is 2005/06/17. This is Fruit 2.1 (Peach).\r
-\r
-Fruit is a UCI-only chess engine. This distribution comes up with\r
-Windows, Linux and Mac OS X executable files as well as an opening\r
-book and platform-independent source code.\r
-\r
-Sorry that the word "Fruit" looks like "Fritz" (it certainly sounds\r
-different in English). This is obviously unintentional (or is it not,\r
-yes? I don't know anymore)!\r
-\r
-PS: How would "Deep Fruit" sound? :)\r
-\r
-\r
-Official distribution URL\r
--------------------------\r
-\r
-The official distribution web site is Leo Dijksman's WBEC Ridderkerk:\r
-http://wbec-ridderkerk.nl/ This is where you should be looking for\r
-Fruit updates in the future.\r
-\r
-\r
-Version\r
--------\r
-\r
-"2.1, what's with the version number? I invested $1M on 2.5 at the\r
-stock market and now who's gonna bring my money back???"\r
-\r
-Not me! Version numbers have nothing to do with chess strength, but\r
-with the quantity of code change and the position of the program in\r
-long-term plans.\r
-\r
-I decided to enter the Massy tournament (2005/06/12) only two weeks\r
-beforehand, and I had to quickly decide for the version that would\r
-play. There were only 3 main changes as compared with Fruit 2.0,\r
-because I had also been working on other programming projects.\r
-\r
-After the tournament, "Fruit Massy" was tested and it appeared obvious\r
-that some strength had been gained. Fruit 2.1 is a "hurry release" of\r
-the tournament version. It took a few more days to fix an interface\r
-problem (hash-table size under Arena) and add opening-book code\r
-(compatible with PolyGlot).\r
-\r
-OK so in short I switched from 2.0 to 2.1 because there were few\r
-changes and I don't especially have plans for a 3.0, sorry for that.\r
-\r
-For a description of the main additions, see the History section.\r
-\r
-\r
-Files\r
------\r
-\r
-The archive contains executable files for Windows, Linux and Mac OS X,\r
-as well as source code and a small opening book.\r
-\r
-The file "technical_10.txt" only concerns the - obsolete - version 1.0\r
-of Fruit (because I am too lazy to edit it right now AND also was when\r
-releasing Fruit 2.0 AND also ...). The search part of it is still\r
-valid for Fruit 2.1 (except for the addition of history pruning).\r
-However the evaluation function has almost been completely re-written.\r
-Again, see the History section for a succinct description.\r
-\r
-\r
-Compiling\r
----------\r
-\r
-The distribution comes up with Windows, Linux and Mac OS X binaries.\r
-Compiling is therefore not necessary on those systems unless you want\r
-to make a change in the program. In any case this section describes\r
-the compiling procedure, it is safe to skip it.\r
-\r
-Fruit was developed on Linux using g++ (the GNU C++ compiler).\r
-\r
-The source code has also been successfully compiled on Windows using\r
-both MSVC and Intel C++ compilers. I do not know about\r
-FreeBSD/OpenBSD/NetBSD or other POSIX-compliant operating systems, but\r
-I don't expect many problems.\r
-\r
-If you had problems getting Fruit compiled on your system, but somehow\r
-managed it in the end, please let me know what changes were necessary\r
-(see the contact section for details).\r
-\r
-I have now included my Makefile for Unix systems. It is a bit weird\r
-(it uses GNU extensions), I hope it works on your OS (let me know if\r
-it doesn't). Associate the "-march" option with the appropriate\r
-value on your system, and type "make" in the "src" directory.\r
-\r
-If you find better optimisation options for g++ please let me know.\r
-\r
-\r
-XBoard / Winboard\r
------------------\r
-\r
-Fruit is a UCI-only engine. This is unlikely to change in the future.\r
-\r
-Fruit and other UCI engines can be used with XBoard or WinBoard (or\r
-other xboard-compatible interfaces) with the help of PolyGlot\r
-(UCI-to-xboard adapter). You can download PolyGlot at\r
-http://wbec-ridderkerk.nl/\r
-\r
-\r
-Opening book\r
-------------\r
-\r
-*** NEW ***\r
-\r
-Starting with version 2.1, Fruit handles an opening book,\r
-tada! (<- Windows 3.x sound for those old enough to remember).\r
-\r
-I cloned the code from my own software (assuming it was legal)\r
-"PolyGlot", sorry myself (it's OK /Ed). And some say that open-source\r
-is not useful!\r
-\r
-Now, I hear it already. Tournament directors will want me to\r
-designate an official book that they should use. To keep download\r
-overhead low, I decided to include only a small book in the main\r
-archive: it's called "book_small.bin". It is in fact the same as\r
-"fruit.bin" in the PolyGlot 1.3 release.\r
-\r
-However, I would prefer that Fruit has access to a larger book during\r
-tournaments. At the time I am writing this line, "book_corbit.bin" is\r
-planned to be made available on WBEC.\r
-\r
-You can build your own book from a PGN file by using PolyGlot on the\r
-command line. PolyGlot is available for download at\r
-http://wbec-ridderkerk.nl/\r
-\r
-\r
-Tablebases\r
-----------\r
-\r
-Fruit does not use the so-called Nalimov tablebases, sorry for that.\r
-This is unlikely to change in the future.\r
-\r
-The reasons for my decision are:\r
-\r
-- the source code by Eugene Nalimov is not "free of use"\r
- (although you don't have to pay for it)\r
-\r
-- the design of the code does not work well with Fruit's "small memory\r
- footprint" requirement (for example the executable file would be at\r
- least twice as large with the TB code).\r
-\r
-It must be said though that I have great respect for Eugene's\r
-contribution to the computer-chess community.\r
-\r
-As for Fruit I plan on using selected "bitbases" in the (very far)\r
-future. For now some draws are recognised by the evaluation function,\r
-and - despite the errors - this somewhat reduces the penalty for not\r
-using tablebases.\r
-\r
-\r
-UCI options\r
------------\r
-\r
-You are advised to skip this section unless you are completely crazy\r
-about computer chess.\r
-\r
-Here I give you another chance to skip the section, as you should not\r
-be reading this ...\r
-\r
-Well you have downloaded Fruit in the first place so I suppose I can't\r
-do anything for you anyway ... I give up!\r
-\r
-- "NullMove Pruning" (Always/Fail High/Never, default: Fail High)\r
-\r
-"Always" actually means the usual conditions (not in check, etc ...).\r
-"Fail High" adds the condition that the static evaluation fails high.\r
-Never use "Never" (ever)! OK you can use "Never" to test a Zugzwang\r
-problem, but ask your Momma first!\r
-\r
-I expect that this option has little effect (assuming the first two\r
-choices only). I only added it because most engines do not use the\r
-fail-high condition.\r
-\r
-- "NullMove Reduction" (1-3 plies, default: 3)\r
-\r
-3 is rather aggressive, especially in the endgame. It seems better\r
-than always using 2 though. I have not experimented with adaptive\r
-solutions.\r
-\r
-- "Verification Search" (Always/Endgame/Never, default: Endgame)\r
-\r
-This tries to solve some Zugzwang-related problems. I expect it to\r
-hardly have any effect in games. The default value should be\r
-sufficient for most-common Zugzwang situations.\r
-\r
-- "Verification Reduction" (1-6 plies, default: 5)\r
-\r
-5 guarantees that the cost of verification search is negligible in\r
-most cases. Of course it means Zugzwang problems need a lot of depth\r
-to get solved, if ever! With such a reduction, verification search is\r
-similar to Vincent Diepeveen's "double null move".\r
-\r
-- "History Pruning" (true/false, default: true)\r
-\r
-A bit dodgy, but fun to experiment with. I added it in Fruit 2.0, and\r
-I still haven't found the time to test it seriously ... It should\r
-help in blitz, but it's possible it actually hurts play in longer\r
-games(!!!). One day, I should check this. One day ...\r
-\r
-- "History Threshold" (percentage, default: 60%)\r
-\r
-This is the thing, as it affects the search tree! Lower values are\r
-safer, and higher values more aggressive. THIS VALUE HAS NOT BEEN\r
-TUNED! There is a good chance Fruit's strength can be improved by\r
-changing this option.\r
-\r
-- "Futility Pruning" (true/false, default: false)\r
-\r
-Very common but controversial. Makes the engine a tiny bit\r
-better at tactics but slightly weaker positionally. It might be\r
-beneficial by a very small amount, but has not been tested in\r
-conjunction with history pruning yet.\r
-\r
-- "Futility Margin" (centipawns, default: 100)\r
-\r
-This value is somewhat aggressive. It could lead to problems in\r
-the endgame. Larger values prune less but will lead to fewer\r
-positional errors.\r
-\r
-- "Delta Pruning" (true/false, default: false)\r
-\r
-Similar to futility pruning. Probably safer because it is used\r
-mainly during the middlegame. Has not been tested with history\r
-pruning either.\r
-\r
-- "Delta Margin" (centipawns, default: 50)\r
-\r
-Same behaviour as futility margin. This one is probably safe.\r
-\r
-- "Quiescence Check Plies" (0-2 plies, default: 1)\r
-\r
-Fruit tries safe (SEE >= 0) checks at the first plies of the\r
-quiescence search. 0 means no checks at all (as in most older\r
-engines). 1 is the same as previous versions of Fruit. 2 is probably\r
-not worth the extra cost. It could be interesting when solving mate\r
-problems though.\r
-\r
-- evaluation options (percentage, default: 100%)\r
-\r
-These options are evaluation-feature multipliers. You can modify\r
-Fruit's playing style to an extent or make Fruit weaker for instance\r
-by setting "Material" to a low value.\r
-\r
-"Material" is obvious. It also includes the bishop-pair bonus.\r
-"Piece Activity": piece placement and mobility.\r
-"King Safety": mixed features related to the king during early phases\r
-"Pawn Structure": all pawn-only features (not passed pawns).\r
-"Passed Pawns": ... can you guess?\r
-\r
-I think "Pawn Structure" is not an important parameter.\r
-Who knows what you can obtain by playing with others?\r
-\r
-\r
-History\r
--------\r
-\r
-2004/03/17 Fruit 1.0, first stable release\r
-------------------------------------------\r
-\r
-Fruit was written in early 2003, then hibernated for many months.\r
-I suddenly decided to remove some dust from it and release it after\r
-seeing the great WBEC web site by Leo Dijksman! Note that Fruit is\r
-nowhere near ready to compete there because of the lack of xboard\r
-support and opening book. Note from the future: these limitations\r
-seem not to be a problem anymore.\r
-\r
-Fruit 1.0 is as close to the original program as possible, with the\r
-main exception of added UCI-handling code (Fruit was using a private\r
-protocol before). It is a very incomplete program, released "as is",\r
-before I start heavily modifying the code (for good or bad).\r
-\r
-You can find a succinct description of some algorithms that Fruit uses\r
-in the file "technical_10.txt" (don't expect much).\r
-\r
-\r
-2004/06/04 Fruit 1.5, halfway through the code cleanup\r
-------------------------------------------------------\r
-\r
-In chronological order:\r
-\r
-- added mobility in evaluation (makes Fruit play more actively)\r
-\r
-- added drawish-material heuristics (makes Fruit look a bit less stupid\r
- in some dead-draw endgames)\r
-\r
-- tweaked the piece/square tables (especially for knights)\r
-\r
-- added time management (play easy moves more quickly, take more time\r
- when unsure)\r
-\r
-- enabled the single-reply extension (to partly compensate for the lack\r
- of king safety)\r
-\r
-- some speed up (but bear in mind mobility is a costly feature, when\r
- implemented in a straightforward way as I did)\r
-\r
-\r
-2004/12/24 Fruit 2.0, the new departure\r
----------------------------------------\r
-\r
-The main characteristic of Fruit 2.0 is the "completion" of the\r
-evaluation function (addition of previously-missing major features).\r
-\r
-In chronological order:\r
-\r
-- separated passed-pawn evaluation from the pawn hash table,\r
- interaction with pieces can now be taken into account\r
-\r
-- added a pawn-shelter penalty; with king placement this forms\r
- some sort of a simplistic king-safety feature\r
-\r
-- added incremental move generation (Fruit was starting to be too slow\r
- for my taste)\r
-\r
-- added futility and delta pruning (not tested in conjunction with\r
- history pruning and hence not activated by default)\r
-\r
-- improved move ordering (bad captures are now postponed)\r
-\r
-- added history pruning (not tested seriously at the time I write\r
- this yet enabled by default, I must be really dumb)\r
-\r
-- cleaned up a large amount of code (IMO anyway), this should allow\r
- easier development in the future\r
-\r
-\r
-2005/06/17 Fruit 2.1, the unexpected\r
-------------------------------------\r
-\r
-Unexpected because participation in the Massy tournament had not been\r
-planned. What you see is a picture of Fruit right in the middle of\r
-development. There may even be bugs (but this is a rumour)!\r
-\r
-I have completed the eval "even more", not that it's ever complete\r
-anyway. I have to admit that I had always been too lazy to include\r
-king attacks in previous versions. However, some programs had fun\r
-trashing Fruit 2.0 mercilessly in 20 moves, no doubt in order to make\r
-me angry. Now they should need at least 25 moves, don't bother me\r
-again!\r
-\r
-- added rook-on-open file bonus; thanks to Vincent Diepeveen for\r
- reminding me to add this. Some games look less pathetic now.\r
-\r
-- added pawn storms; they don't increase strength but they are so\r
- ridiculous that I was unable to deactivate them afterwards!\r
-\r
-- added PV-node extensions (this is from Toga), e.g. extending\r
- recaptures only at PV nodes. Not sure if these extensions help; if\r
- they do, we all need to recognise Thomas Gaksch's contribution to\r
- the community!\r
-\r
-- added (small) king-attack bonus, the last *huge* hole in the eval;\r
- now only large holes remain, "be prepared" says he (to himself)!\r
-\r
-- added history-pruning re-search; does not help in my blitz tests,\r
- but might at longer time control; it's also safer in theory,\r
- everybody else is using it and I was feeling lonely not doing like\r
- them. OK, Tord told me that it helped in his programs ...\r
-\r
-- added opening book (compatible with PolyGlot 1.3 ".bin" files)\r
-\r
-- fixed hash-size UCI option, it should now be easy to configure using\r
- all interfaces (there used to be problems with Arena, entirely by my\r
- fault)\r
-\r
-\r
-Breakpoint\r
-----------\r
-\r
-Why a breakpoint now? For the first time of its life, after the\r
-recent addition of king attacks, Fruit has all major (but admittedly\r
-few others) evaluation components. Don't get me wrong: they all need\r
-a lot of refinement, but the code layout is there.\r
-\r
-When Fruit 1.0 was released, some programmers told their surprise\r
-that the program was playing OK-ish (not that I agreed) despite having\r
-virtually no eval. They might have wondered whether their larger code\r
-was really useful.\r
-\r
-Since then, I have mostly added classical evaluation features. I\r
-believe that Fruit has gained overall 150 to 200 Elo points by\r
-evaluation alone. Here I just want to explain that the minimalism of\r
-Fruit 1.0 was never a goal, but the consequence of the "as is" state\r
-of the distribution.\r
-\r
-In the end, the moral is safe: eval is good for you!\r
-Also "don't jump at conclusions" seems appropriate.\r
-\r
-\r
-Future?\r
--------\r
-\r
-Because of this "hurry release", I haven't had the time to continue\r
-cleaning up the code. This is the main reason why the version number\r
-is only 2.1\r
-\r
-I hope to provide a cleaner alternative, perhaps tuned a little, in a\r
-few months. Maybe it is time to consider adding features like\r
-MultiPV.\r
-\r
-Although I believe I could keep on increasing strength by adding more\r
-and more eval terms, I have little interest in doing so. I would not\r
-learn anything in the process, unless I develop new tuning/testing\r
-techniques. Ideally I would like to spend more time in alternative\r
-software, like my own GUI perhaps (specific to engine testing/matches).\r
-\r
-Nonetheless, a lot can be done like tuning existing code or building\r
-an adapted opening book. Therefore, don't hesitate to contact me if\r
-you are interested in giving a hand. Computer testing time is\r
-especially welcome, but be warned that I am quite demanding. "I can\r
-include test versions in my Fritz-GUI swiss tournament." -> forget it,\r
-as well as my email address please, thanks a lot!\r
-\r
-Lastly, don't take it too seriously. I am tired and always under big\r
-pressure before a release, because I want everything to go smoothly.\r
-Who knows what I will think in a month?\r
-\r
-\r
-Bug fixes\r
----------\r
-\r
-Contrary to Fruit 2.0, Fruit 2.1 checks the legality of the hash-table\r
-move before playing it. This could make Fruit 2.0 crash in rare\r
-occasion (like once every 10000 games). This means that if Fruit 2.1\r
-crashes, the bug is somewhere else.\r
-\r
-Fruit 2.1 will now tolerate a hash-table resize after initialisation.\r
-This seems especially important for use with Arena. Unfortunately, it\r
-also raises the notorious 1MB problem of some "bug"-full interface ...\r
-\r
-\r
-Known bugs\r
-----------\r
-\r
-Fruit always claims that CPU is 100% used. This is apparently a\r
-problem in the standard C libraries on Windows. Mailbomb me if fixing\r
-this would save lives (especially children)! I prefer waiting for\r
-late users to throw away Windows 95/98/ME before adding an\r
-NT/2000/XP/... solution.\r
-\r
-\r
-Thanks\r
-------\r
-\r
-Big thanks go to:\r
-\r
-- Joachim Rang and Robert W. Allgeuer for spending so much time\r
- testing different versions/settings of Fruit and getting actively\r
- involved in the project in general. I don't know why they got\r
- interested in Fruit but the current version would definitely NOT\r
- exist without them.\r
-\r
-- Bryan Hofmann for compiling Fruit (and other engines) for Windows\r
-\r
-- Aaron Gordon for the Linux binary and long-term friendship;\r
- he's the one who showed me CCC years ago!\r
-\r
-- George Sobala for the Mac OS X executable\r
-\r
-- Leo Dijksman for hosting the Fruit distribution (and also the\r
- PolyGlot adapter) on his web site (see Links) and all the rest:\r
- tournament, testing, documentation, etc, ... For those who have not\r
- noticed (e.g. people still using a TRS-80), Leo is EXTREMELY serious\r
- in what he is doing. A reference in behaviour!\r
-\r
-- Ernest Bonnem for making it possible for Fruit to play in the\r
- Massy 2005 tournament\r
-\r
-- Tord Romstad for being my virtual twin brother; who knows if we can\r
- materialise in the same place some day?\r
-\r
-- You, for having patiently waited for this release and still being\r
- reading this file (don't worry, it's nearly finished)\r
-\r
-As usual there are dozens missing, it is simply impossible to include\r
-everybody.\r
-\r
-\r
-Links\r
------\r
-\r
-- engine lists, and much more:\r
-\r
-Leo Dijksman's WBEC Ridderkerk: http://wbec-ridderkerk.nl/\r
-Alex Schmidt's UCIengines.de: http://www.uciengines.de/\r
-\r
-- free chess GUIs:\r
-\r
-Tim Mann's Chess Pages: http://www.tim-mann.org/xboard.html\r
-Arena: http://www.playwitharena.com/\r
-\r
-- computer-chess fora:\r
-\r
-The Computer Chess Club (CCC): http://www.talkchess.com/\r
-Volker Pittlik's Winboard Forum: http://wbforum.volker-pittlik.name/\r
-\r
-- mostly programmer stuff (if you have several lives to spend):\r
-\r
-Dann Corbit's FTP: ftp://cap.connx.com (do *not* use passive mode)\r
-\r
-Sorry for the dozens I simply had to leave away (but you know them if\r
-you went that far) ...\r
-\r
-\r
-Contact me\r
-----------\r
-\r
-You can contact me at fabien_letouzey@hotmail.com\r
-\r
-For a long time, I have been waiting in vain for the "Fruit Fan Club"\r
-T-shirts and donations of source-code improvements of several hundreds\r
-Elo points I had been asking for. About the latter I have to say that\r
-it is not very smart to delay much further: the more you wait and the\r
-more difficult it will be, but I suppose that it had not yet been\r
-challenging enough ...\r
-\r
-Anyway, I have decided to launch a new initiative. What's more boring\r
-than reading one's own code at 3am tracking down a bug that might not\r
-even exist, know what I mean? I have the solution: let's fix\r
-each others bugs!\r
-\r
-The new operation is called "Fix my Bugs and I Fix Yours!" (patent\r
-pending). It works as follows:\r
-\r
-1) You fix one of my bugs (excluding null move) before 2005/09/01\r
- 00:00 UTC (the acronym that does not mean anything in either\r
- English or French, so that both parties are equally disappointed).\r
-\r
-2) I select the most artistic bug fix after the date limit. A jury\r
- will be nominated if necessary.\r
-\r
-3) I fix a bug of your choice in your program (excluding "it plays bad\r
- moves"), it's that simple!\r
-\r
-This is not irony: contrary to popular belief, there really are bugs\r
-in Fruit. Even search bugs. I just couldn't be bothered with fixing\r
-them so far. Sorry that I can't give you more hints, for now I am\r
-using them to find clones effortlessly.\r
-\r
-See you in September!!!\r
-\r
-\r
-The end\r
--------\r
-\r
-Thanks for listening, and have fun with Fruit!\r
-\r
-Fabien Letouzey, 2005/06/17.\r
-\r
projects / xboard.git / blobdiff