[computer-go] Comprehensive List of Docs
Let this list, and all replies be a comprehensive list of websites and docs publically availble concerning Go dev. -Josh ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Go with modified scores
Some replies on my original mail indicate that I did not make clear the motivation of my proposal. You have to distinguish several scenarii when maximizing the playing strength/value of your Go program: (a) auto-play (or play between different versions of your prog) (a') play against other computer programs (b) play against humans (c) program as tool for human analysis of Go positions or of whole games (d) acceptance by humans I agree, that for (a) and (a') other scoring rules will likely not give better results. But concerning (b) I am not so sure. Here, data from KGS may shed some light. Did some programmers try to test ohter scoring systems there? Concerning (c), I can tell from my experiences in the computer chess world. In the late 1990's strong Shredder and Junior were dominating the computer chess tournaments. However, as analysis tools they were not the best. Concerning (d), in the German go scene several people who tested Leela, were not at all convinced by the playing style, even not on 9x9. And this was not based on performance, but mainly on the laziness. My claim was (and still is): Other scoring schemes (inside the programs) may prove beneficial with respect to (b), (c), (d). Ingo. *** Denis Fidaali asked: how can i do so that my response to this mailing-list will be correctly indented ? (for example i would have liked to set this one as a response to my previous post). Not an answer, but I am suffering the same problem -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go with modified scores
You have to distinguish several scenarii when maximizing the playing strength/value of your Go program: (a) auto-play (or play between different versions of your prog) (a') play against other computer programs (b) play against humans (c) program as tool for human analysis of Go positions or of whole games (d) acceptance by humans By the way, there has been a game won by mogo against a high-level player in which, sure of winning by at least 0.5, mogo has given several points to his opponent. The human player was not offended, as he could of course understand that we are not responsible for this choice of mogo, but he pointed out that this is done in human games only - in a discrete manner, when you just want to win by a small amount, by politeness; in that case you do it in a discete manner, and it's fine; - in a very obvious way, when you want to point out that the opponent should definitely resign now. Best regards, Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] programming (languages) light-simulation contest
[computer-go] programming (languages) light-simulation contest The reason i have been eager to make so sure my implementation was conform to what i had in mind (this time ..) is that i wanted to be able to test various (possibly a lot) of different implementations in different environments (machines, langages, memory etc etc ..). So far i have developed simple light simulators for those environments : (all single threaded) - Java 32 bits. - C 32 bits linux. - C 64 bits linux - Assembly 32 bits on some intel duo with no SSE - Assembly 32 bits on some intel duo with some SSE - Assembly 64 bits with and without SSE - NVIDIA Cuda C I was quite dissatisfied with the results. The development cycle was just too long, there was just too many things to be tuned and tried. I got lost in the different versions not remembering how it had been validated, and more than often plainly loosing where the code was (i used more than 5 computers, most of witch are not there anymore - with no clear backup strategy) , when it had not been changed to death anyway (without backing up - so not much left to recover). So i figured out, what i had a need for to begin with, was method. - I have followed loosly those hey here is a new interesting language conversations. My conclusion where always the same : it's just a confrontation of random thoughts. So i kinda stopped trying to follow them. I think things are started to go in a good direction now : it's mostly useless to talk about ideas, or unverifiable data in a list like this one. So what i like a lot about how things are going now, is that it seems that the community has got here a strong will to get something to talk-about in the first place. Still i hardly anticipate this to gives something fruitful in the end. That would be because everyone's goal seems different from everyone's else. I guess that there is a goal worth pursuing underlying the conversation. I see such a goal for myself. Which would be to answer the question : what does a really good version of light playout looks like. I chose light playouts because it's so easy now to agree on an implementation : most people seems to use quite exactly the same one. That's why i was able to just ask for other to confirm that mine was correct. By the way, i think that AMAF implementation based on those light-play-out, is straight forward too. That's why i chose those to try to get the most out of everybody's else experience. As for me, i'm really NOT interested in knowing what langage is good for go programming. That's simply not a question i can ask myself, nor anyone else. This question doesn't make any sense for me. Still if someone can get the standard light playout right in less than 10 code line, and they are very understandable lines. I would be very happy to see it. But it would never mean for me that, this language is BEST. Even if the peformances are optimal there. I think 90% of the this language is the best debate gets it's root in some affective part of the people engaged with it. So .. i'm not interested at all in a langage contest. I really don't care about that. Still i find interesting to argue over facts, rather than about random thoughts. Now, to really set the frame-rules of this language contests seems a challenge really interesting in itself. I don't think it'll be easy to do. I think that it has to be so that most people do agree that it has been set up properly. And then, it has to be so, that absolutely anybody that has the slightest interest in the matter will be able, and will be willing to participate. I didn't really put a lot of thought in it, but here are what i can think of right now. -It should be useful. So let's make it a programming contest, rather than a pure language contest. It may be slower to get enough data to be able to compare different languages.But then it'll make it so that more people can participate and find values in it. I would never try anything for a language contest myself. But i may well want to invest some time in a programming contest. So when i say it should be useful the question i really ask is : what information (or benefices) should we hope to get out of this challenge. That would both help us to get nice ideas about how to set it, and a base for discussing if what we proposed is right or wrong. And then later on, we can compare the real benefice of it, with what we expected to get. - It should allow a lot of freedom. Once again this is based on the assumption, that it is most probable that NOBODY will actually join the contest. So we have to get it as wide as possible, as
[computer-go] Beijing photo
Hi, I put some photos in Beijing Computer Go tournament. http://yssaya.web.fc2.com/photo/beijing2008/beijing2008.html Regards, Hiroshi Yamashita ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Questions of Beijing photos
Hello Hiroshi, thanks for the many nice photos from Beijing. I have a few questions (indeed, I have many, but will ask only a few of them): * On which picture(s) can I find you? * Is Feng Hsiung Hsu (guest of honor, when I understand correctly) on some of your pictures? * Is the programmer of HandTalk on some of the pictures? * What was the level of play on (11x11)-Hex? * Who is sitting left of Johan de Koning on 2444? * Who is the beautiful woman on 2501? * The two guys on 2552, I know only one of them. Who is the other? * What is shown on 2559? * What are the lights on 2587? * Who is the left person on 2639 (an uncle of Johan de Koning?) * Is 2711 from the final game of the 9x9-playoff? Thanks again for the pictures, and thanks in advance for your explanations. Best regards, Ingo -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Questions of Beijing photos
Hi Ingo, * On which picture(s) can I find you? http://yssaya.web.fc2.com/photo/beijing2008/1002/Htmls/PICT2554.html Left is me. * Is Feng Hsiung Hsu (guest of honor, when I understand correctly) No, I think he did not come. * Is the programmer of HandTalk on some of the pictures? No, professor Chen Zhixing did not come. * What was the level of play on (11x11)-Hex? Sorry, I don't know. * Who is sitting left of Johan de Koning on 2444? He is Julien Kloetzer. * Who is the beautiful woman on 2501? Beautiful lady is always secret. * The two guys on 2552, I know only one of them. Sorry, I don't know. * What is shown on 2559? Other side Great Wall, but we cound not see well for smog. * What are the lights on 2587? Street lights about the pond. * Who is the left person on 2639 (an uncle of Johan de Koning?) He is an author of Stone Fighter. * Is 2711 from the final game of the 9x9-playoff? No, this is not final game. Final game was played next night. Regards, Hiroshi Yamashita - Original Message - From: Ingo Althöfer [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Friday, October 10, 2008 10:12 PM Subject: [computer-go] Questions of Beijing photos Hello Hiroshi, thanks for the many nice photos from Beijing. I have a few questions (indeed, I have many, but will ask only a few of them): * On which picture(s) can I find you? * Is Feng Hsiung Hsu (guest of honor, when I understand correctly) on some of your pictures? * Is the programmer of HandTalk on some of the pictures? * What was the level of play on (11x11)-Hex? * Who is sitting left of Johan de Koning on 2444? * Who is the beautiful woman on 2501? * The two guys on 2552, I know only one of them. Who is the other? * What is shown on 2559? * What are the lights on 2587? * Who is the left person on 2639 (an uncle of Johan de Koning?) * Is 2711 from the final game of the 9x9-playoff? Thanks again for the pictures, and thanks in advance for your explanations. Best regards, Ingo -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] pseudo eye variations for playouts
Thanks everyone for the answers regarding playout terminations. I still have my suspicions regarding how artificial game length bounds affect the position evaluation (I'd expect the values to fluctuate with length, so arbitrary bounds would result in arbitrary differences). For the moment, however, I'd like to focus on the variations wrt pseudo-eyes (positions not to be filled during playouts). All of these are known to be wrong in some cases, the main argument in favour of pseudo-eyes being efficiency. Since ruling out fill-ins introduces not only biases, but actual blind spots into the playouts, something even heavy playouts otherwise try to avoid (they prioritize good moves instead of eliminating bad moves) it is important that the definition of pseudo-eyes errs on the safe side (safe here meaning random play - any move is possible): they may permit erroneous fill-ins, but must not rule out necessary fill-ins (only definitely bad fill-ins may be ruled out). Within that constraint, the goal is to rule out as many bad fill-ins as possible without ruling out any good fill-ins. And all three variations listed earlier (Gobble, Olga, Oleg) http://computer-go.org/pipermail/computer-go/2008-October/016549.html have their issues with that. For instance, consider the following position: ( ; FF[1] GM[1] SZ[19] AP[Jago:Version 5.0] AB[ji][kj][jk][ij][jl][hj][jh][lj][jg][kf][ke][le][me][ne][of][og][oh][oi][ni][mj][nf][kg][nj][jm][jn][jo][jp][ip][hp][gp][fp][fo][fn][fm][fl][fk][fj][gj][gi][gh][hg][ig][ok][gf][pl][fe] AW[ki][kh][li][lg][mh][lf][mf][ng][nh][kk][lk][kl][mi][mk][nk][ik][hk][gk][gl][gm][gn][il][im][in][io][go][hm][ho][jd][kd][ld][md][nd][od][pe][pf][ph][pg][pi][pj][ei][ej][ek][el][em][en][eo][ep][eq][fq][gq][hq][iq][jq][kq][ko][kp][kn][km][oj][ii][fi][fh][fg][gg][hf][if][jf][je][ih][oe] C[black to move. Gobble: 'a' is not an eye = fill it and die Olga: 'a' is an eye, but would cease to be if 'b' was white Oleg: 'a' is not an eye, but would be if 'b' was black] L[jj][hh][nk][oj] GN[playout-eyes] ) If I set this up correctly, the black center group is unconditionally alive, even if it was white's turn, while playouts with Gobble-style pseudo-eyes will rate it as unconditionally dead (and hence the white strings 'c' and 'd' as unconditionally alive, independent of conditions on the outside). Playouts with Olga-style pseudo-eyes would fare better, but would be fooled into considering fill-in at 'a' after white 'b'. Playouts with Oleg-style pseudo-eyes have a chance of finding the black group alive, in case of black 'b' first. Did I set this up right? And why does no-one else seem worried about it?-) Claus PS In case the sgf-labelling isn't standard, 'a' is K10/center, 'b' is H12. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] pseudo eye variations for playouts
Claus Reinke wrote: ... Gobble: 'a' is not an eye = fill it and die Olga: 'a' is an eye, but would cease to be if 'b' was white Oleg: 'a' is not an eye, but would be if 'b' was black] L[jj][hh][nk][oj] GN[playout-eyes] ) If I set this up correctly, the black center group is unconditionally alive, even if it was white's turn, while playouts with Gobble-style pseudo-eyes will rate it as unconditionally dead (and hence the white strings 'c' and 'd' as unconditionally alive, independent of conditions on the outside). Playouts with Olga-style pseudo-eyes would fare better, but would be fooled into considering fill-in at 'a' after white 'b'. Playouts with Oleg-style pseudo-eyes have a chance of finding the black group alive, in case of black 'b' first. Did I set this up right? And why does no-one else seem worried about it?-) Has anyone tried or considered trying this idea: Select a random eye definition at the start of each playout? Or perhaps a weighted random selection if you have some information about how to weight them. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Oct 10, 2008, at 2:10 PM, Stuart A. Yeates wrote: On Sat, Oct 11, 2008 at 10:05 AM, terry mcintyre [EMAIL PROTECTED] wrote: I like the idea of a contest to determine the best ways to implement a particular problem ( generating light playouts ) in various languages. The Language Shootout is probably not the best forum, since they require the same algorithm, which defeats the purpose of comparing languages which tend to do different things well by design; a good programmer/advocate would play to the strengths of each language. The Language shootout has a class of contests which do not require the same algorithm, i.e. http://shootout.alioth.debian.org/u32q/benchmark.php? test=meteorlang=all cheers stuart The Alioth site is centrally administrated, so the bureaucracy to add a task is formidable. On the other hand, they've just added a multicore test platform and already have a performance measuring framework. Might I suggest again the Rosetta Code wiki at http:// www.rosettacode.org/? Anyone can contribute at any time, since it's uses MediaWiki, like Wikipedia. They have active participants for many compiled languages, and have just been discussing adding a game category. I would especially like to see what the J and Haskell folks make of this task. For a larger project like this, they recommend making a single task page with a sub page for each language (like RCBF). Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] pseudo eye variations for playouts
There is a de facto standard light playout policy (algorithm). If you want to adhere to this standard, then by definition, there are correct and incorrect ways to do so. If you just want to design a better playout policy, naturally anything is fair game. But how are you going to measure whether it's really better? My advice is to keep to this standard for a little while longer, write the rest of your engine, run it on CGOS where you can compare it directly with programs like myCtestxxx (maintained for that purpose by generous individuals) and verify that the other parts work. Then start improving the playout policy. Just my suggestion. - Dave Hillis -Original Message- From: Claus Reinke [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Fri, 10 Oct 2008 4:54 pm Subject: [computer-go] pseudo eye variations for playouts Thanks everyone for the answers regarding playout terminations. I still have my suspicions regarding how artificial game length bounds affect the position evaluation (I'd expect the values to fluctuate with length, so arbitrary bounds would result in arbitrary differences). For the moment, however, I'd like to focus on the variations wrt pseudo-eyes (positions not to be filled during playouts). All of these are known to be wrong in some cases, the main argument in favour of pseudo-eyes being efficiency. Since ruling out fill-ins introduces not only biases, but actual blind spots into the playouts, something even heavy playouts otherwise try to avoid (they prioritize good moves instead of eliminating bad moves) it is important that the definition of pseudo-eyes errs on the safe side (safe here meaning random play - any move is possible): they may permit erroneous fill-ins, but must not rule out necessary fill-ins (only definitely bad fill-ins may be ruled out). Within that constraint, the goal is to rule out as many bad fill-ins as possible without ruling out any good fill-ins. And all three variations listed earlier (Gobble, Olga, Oleg) http://computer-go.org/pipermail/computer-go/2008-October/016549.html have their issues with that. For instance, consider the following position: ( ; FF[1] GM[1] SZ[19] AP[Jago:Version 5.0] AB[ji][kj][jk][ij][jl][hj][jh][lj][jg][kf][ke][le][me][ne][of][og][oh][oi][ni][mj][nf][kg][nj][jm][jn][jo][jp][ip][hp][gp][fp][fo][fn][fm][fl][fk][fj][gj][gi][gh][hg][ig][ok][gf][pl][fe] AW[ki][kh][li][lg][mh][lf][mf][ng][nh][kk][lk][kl][mi][mk][nk][ik][hk][gk][gl][gm][gn][il][im][in][io][go][hm][ho][jd][kd][ld][md][nd][od][pe][pf][ph][pg][pi][pj][ei][ej][ek][el][em][en][eo][ep][eq][fq][gq][hq][iq][jq][kq][ko][kp][kn][km][oj][ii][fi][fh][fg][gg][hf][if][jf][je][ih][oe] C[black to move. Gobble: 'a' is not an eye = fill it and die Olga: 'a' is an eye, but would cease to be if 'b' was white Oleg: 'a' is not an eye, but would be if 'b' was black] L[jj][hh][nk][oj] GN[playout-eyes] ) If I set this up correctly, the black center group is unconditionally alive, even if it was white's turn, while playouts with Gobble-style pseudo-eyes will rate it as unconditionally dead (and hence the white strings 'c' and 'd' as unconditionally alive, independent of conditions on the outside). Playouts with Olga-style pseudo-eyes would fare better, but would be fooled into considering fill-in at 'a' after white 'b'. Playouts with Oleg-style pseudo-eyes have a chance of finding the black group alive, in case of black 'b' first. Did I set this up right? And why does no-one else seem worried about it?-) Claus PS In case the sgf-labelling isn't standard, 'a' is K10/center, 'b' is H12. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Oct 9, 2008, at 10:39 PM, Don Dailey wrote: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my random playouts looks the disturbingly similar? As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. This is true, but it goes back to the well understood fact that you cannot have a perfect benchmark. I think this would be very useful and very relevant, just not perfect. Random numbers IS an issue. I required transparency so that any issue like this can be observed, reviewed, criticized, etc. However, there is a solution. I don't think this solution is necessary, but it is possible: George Marsaglia published a set of very high quality random number generators that can be implemented with just a couple of lines of code. We could specify that a specific random number generator be used. After all, this is only a benchmark. But these are fast generators. The final step, which I don't personally support because I think it's too restrictive but is also possible is to require these programs to be deterministic.So you could SPECIFY the exact starting seed for a random number generator as well as the specific method (or equivalent) to be used to select moves randomly. I don't really like that idea, but it makes it possible to perfectly verify the implementations. I don't like it simply because it places additional constraints on creativity and flexibility. You might come up with a very clever and fast way to generate uniformly random moves for instance that doesn't work within the framework. Or you may want to benchmark some language that doesn't like 32 bit data types (perhaps 31 bit types for instance.) A lack of flexibility here would unduly punish you. So I'm happy to allow some leeway at the expense of perfect verification as long as we have transparency, anybody who wants can see the code and criticize it or find flaws. (His implementation is FAST, but he cheated a little on the random numbers.) It's also pretty easy to not pick moves uniformly random - I think some on this group may have made that mistake. This should show up if we have good benchmarks. Someone will notice something slightly off in the statistics reported and it will be examined or seen to be flawed. hi, i hate usually replies to my post that zoom in into 1 tiny detail, apologies for doing that. However i'd like to zoom in on the uniformity of RNG's. Of course we all do effort to get uniform RNG's. In fact the net is overloaded with them. Years ago i googled and i stumbled upon ranrot from Agner Fog. http://www.agner.org/random/theory/ Like all fibonacci based RNG's it's completely uniform spreaded. Now THAT has a few problems. When i did do some work a year or 8 ago for a guy called Avery Cardoza, he released a game called Casino2000. Obviously it also has roulette also. Now if we take the European roulette version that has a single zero (US casino's have 2 zero's, a 0 and 00, which makes odds quite bigger for casino), there is on paper 1 strategy that might deliver money. Might, because playing with a system is forbidden of course. On paper there is 1 system that wins. You put 1 fiche, then if you lose that bet you double, if you lose again you double again. So you bet 1,2,4,8,16,32,64,128,256,512,1000 Hah, why 1000? Because usually you won't get further than doubling 10 times. Each table has a max bet. So let's limit the number of bets to 8. 7 doublings in short. Not a single RNG that is considered to be 'good' and 'well'. Yes not even Mersenne twister, is *approaching* reality there that happens in casino's. Now i do not mean the 'bad' casino's, but simply that the profit you make on paper is a lot higher than in reality (other than that they'll kick you out of the casino). The freakin nature of all those bitflippers is such that i'm *assuming* nowadays in some algorithms that they can produce a field for me in O ( n log n ). So not only they are too uniform, they also can produce an entire field, covering every element in O ( n log n), without a single failure. Now THAT'S interesting :) - Don - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 9 Oct 2008 2:44 pm Subject: Re: [computer-go] programming languages On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. Many potential ways to speed up light playouts involve
Re: [computer-go] programming languages
Sure,
A lot faster is ranrot in 64 bits, at K8 2.2ghz with old GCC it is
about 3.3 ns for each number,
so i assume it's quite a tad faster than that for core2. Note it's
quite slow at itanium,
about 9-10 nanoseconds a number, as it appeared later itanium has no
rotate hardware instructions :)
Here is how i rewrote it:
/* define parameters (R1 and R2 must be smaller than the integer
size): */
#define KK 17
#define JJ 10
#define R1 5
#define R2 3
#define BITBOARD (unsigned long long)
/* global variables Ranrot */
BITBOARD randbuffer[KK+3] = { /* history buffer filled with some
random numbers */
0x92930cb295f24dab,
0x0d2f2c860b685215,0x4ef7b8f8e76ccae7,0x03519154af3ec239,0x195e36fe715fa
d23,
0x86f2729c24a590ad,0x9ff2414a69e4b5ef,
0x631205a6bf456141,0x6de386f196bc1b7b,0x5db2d651a7bdf825,
0x0d2f2c86c1de75b7,0x5f72ed908858a9c9,0xfb2629812da87693,0xf3088fedb657f
9dd,0x00d47d10ffdc8a9f,
0xd9e323088121da71,0x801600328b823ecb,
0x93c300e4885d05f5,0x096d1f3b4e20cd47,0x43d64ed75a9ad5d9
/*0xa05a7755512c0c03,0x960880d9ea857ccd,0x7d9c520a4cc1d30f,
0x73b1eb7d8891a8a1,0x116e3fc3a6b7aadb*/
};
int r_p1, r_p2; /* indexes into history buffer */
/ AgF
1999-03-03 *
* Random Number generator 'RANROT' type
B *
* by Agner
Fog *
*
*
* This is a lagged-Fibonacci type of random number generator
with *
* rotation of bits. The algorithm
is: *
* X[n] = ((X[n-j] rotl r1) + (X[n-k] rotl r2)) modulo
2^b *
*
*
* The last k values of X are stored in a circular buffer
named *
*
randbuffer. *
*
*
* This version works with any integer size: 16, 32, 64 bits
etc.*
* The integers must be unsigned. The resolution depends on the
integer *
*
size. *
*
*
* Note that the function RanrotAInit must be called before the
first*
* call to RanrotA or
iRanrotA *
*
*
* The theory of the RANROT type of generators is described
at *
* www.agner.org/random/
ranrot.htm *
*
*
*/
FORCEINLINE BITBOARD rotl(BITBOARD x,int r) {return(xr)|(x(64-r));}
/* returns a random number of 64 bits unsigned */
FORCEINLINE BITBOARD RanrotA(void) {
/* generate next random number */
BITBOARD x = randbuffer[r_p1] = rotl(randbuffer[r_p2],R1) + rotl
(randbuffer[r_p1], R2);
/* rotate list pointers */
if( --r_p1 0)
r_p1 = KK - 1;
if( --r_p2 0 )
r_p2 = KK - 1;
return x;
}
/* this function initializes the random number generator. */
void RanrotAInit(void) {
int i;
/* one can fill the randbuffer here with possible other values
here */
randbuffer[0] = 0x92930cb295f24000 | (BITBOARD)ProcessNumber;
randbuffer[1] = 0x0d2f2c860b000215 | ((BITBOARD)ProcessNumber12);
/* initialize pointers to circular buffer */
r_p1 = 0;
r_p2 = JJ;
/* randomize */
for( i = 0; i 300; i++ )
(void)RanrotA();
}
Please note there is faster RNG's than ranrot, with some shifting
here and there.
But maybe ranrot is what is sufficient. You won't search enough nodes
coming 10
years to get in trouble with it :)
Note that the parameter 'processnumber' is the process number of each
process (or thread)
of search. Safely works up to 4096 cores :)
On Oct 10, 2008, at 12:36 AM, Don Dailey wrote:
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
Computers + random = can of worms.
Has anyone seen this:
http://home.southernct.edu/~pasqualonia1/ca/report.html#files
They are claiming impressive speed and high quality for a random
number
generator. The code is compact and small, much nicer than mt19937
and
the speed seems to blow mt19937 out of the water.
I haven't looked at any papers on this and I'm wondering how good
it is.
Here is quote:
The cellular automaton outperforms the GSL random number
generators, being more than three times as fast as the GSL
generators.
The following table shows the mean time for 10 runs of each
generator, with each run producing 10 million integers. Source
code for both the GSL generators and the cellular
