Re: [computer-go] Monte-Carlo Go simulation

2007-02-09 Thread alain Baeckeroot
Le jeudi 8 février 2007 22:09, Sylvain Gelly a écrit : It seems i was ambiguous: I was speaking of the simulation player too. What i meant is a random simulation player is not biased, whereas a better simulation player is biased by its knowledge, and thus can give wrong evaluation of a

Re: [computer-go] MC Go Effectiveness

2007-02-09 Thread Ephrim Khong
Unknown wrote: BTW: once you choose the /8 gain by implementing canonicalization, you'll probably want to implement /2 color-swaps, too. (but this will only be profitable for libraries, not for 'history' such as in Don's case.) The /2 with color-swaps would work fine with librarys that don't

Re: [computer-go] MC Go Effectiveness

2007-02-09 Thread Don Dailey
On Fri, 2007-02-09 at 13:19 +0100, Ephrim Khong wrote: The /2 with color-swaps would work fine with librarys that don't store the whole gamestate, but I doubt it's worth implementing it in fuseki-librarys: Since there are usually no or very few captures during the fuseki, the player whos turn

[computer-go] pure random mode

2007-02-09 Thread Don Dailey
Hi Sylvain, In the MoGo report paper, you make this statement: We also privilege the moves eating some stones. This refers to a version of MoGo that doesn't have the pattern knowledge and you call it the pure random mode. My program does this too but in a probabilistic way. I'm curious

Re: [computer-go] pure random mode

2007-02-09 Thread Sylvain Gelly
Hi Don, In the MoGo report paper, you make this statement: We also privilege the moves eating some stones. This refers to a version of MoGo that doesn't have the pattern knowledge and you call it the pure random mode. My program does this too but in a probabilistic way. I'm curious

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread wms
Peter, java serialization is not a good way to do persistent storage of any kind, especially large data structures. It has some pretty severe drawbacks:

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread terry mcintyre
Is this opening book database used for the UCT portion, or the playout portion of Orego? In the UCT portion, speed of access may not be that important; a database would probably be ideal. If used during the playout, then speed of access is more crucial. Terry McIntyre UNIX for hire software

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread Peter Drake
On Feb 9, 2007, at 10:48 AM, Nick Apperson wrote: What type of data are you trying to serialize or rather store to disk? Do you have pointers in the data. Don't tell me you don't have pointers just because it is java. I wouldn't dream of it. Java has pointers and I use the hell out of

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread Peter Drake
The UCT portion. I'm storing/loading a pre-built UCT tree once at startup; the disk is not accessed during the game. Peter Drake Assistant Professor of Computer Science Lewis Clark College http://www.lclark.edu/~drake/ On Feb 9, 2007, at 11:08 AM, terry mcintyre wrote: Is this opening

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread Stuart A. Yeates
I serialised some very large Markov models (tens to low hundreds of megabytes) for my PhD using java serialisation. A couple of hints: *) they can be faster if you compress them (I used the standard Java libraries). Disk access was the limiting factor in my case and compression (I got 80%

[computer-go] Zobrist hashing with easy transformation comparison

2007-02-09 Thread Nick Apperson
Hey all, I was thinking about our conversation and i decided to design a zobrist class that allows for easy comparison to check and see if 2 different zobrist values are equivalent after a rotation etc... It updates the zobrist in such a way that it can transform them and after trying 8

Re: [computer-go] MC approach

2007-02-09 Thread Weston Markham
I don't seem to have any numbers on this anymore, but I should be able to try some experiments this weekend. I do have some code that does what I describe below. It is also using an all moves as first heuristic. According to my notes, I made this change in an attempt to avoid severely

Re: [computer-go] Zobrist hashing with easy transformation comparison

2007-02-09 Thread Antoine de Maricourt
Hi, did you read Anti Huima's paper? The idea looks similar, but unfortunately it does not work. I provided a proof of the defect on this list (end of 2002 if I remember well). It's not that easy to get a working scheme. In fact there is only one combination with 8 chunks of data. In 2002 I

RE: [computer-go] Serializing a very large object in Java

2007-02-09 Thread Lucas, Simon M
Three alternative options to Java's native serialisation: * Object database db4o: http://db4o.com * WOX (Web Objects in XML) (my own) http://algoval.essex.ac.uk/wox/serial/readme.html * JSON (JavaScript Object Notation) - also has Java libraries. Simon Lucas -Original

Re: [computer-go] Zobrist hashing with easy transformation comparison

2007-02-09 Thread Łukasz Lew
On 2/10/07, Antoine de Maricourt [EMAIL PROTECTED] wrote: Hi, did you read Anti Huima's paper? The idea looks similar, but unfortunately it does not work. I provided a proof of the defect on this list (end of 2002 if I remember well). It's not that easy to get a working scheme. In fact there is

Re: [computer-go] Zobrist hashing with easy transformation comparison

2007-02-09 Thread Nick Apperson
Sorry for posting then, I didn't realize that it had been tried. I may work through the problem and try to get it to work in order to fully understand why it in fact does not work. If by some miracle I manage to get something working with a collision rate of 1/(2^61) I'll certainly post it.

Re: [computer-go] Serializing a very large object in Java

2007-02-09 Thread Ray Tayek
At 09:55 AM 2/9/2007, you wrote: ..., Java has a stack overflow error. i assume you have tried the java -Xss to set the stack size (type java -X for help on these)? thanks --- vice-chair http://ocjug.org/ ___ computer-go mailing list