--- /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