most users use a client and never use the commandline
or read the help pages. It was started because some (polish?,Chinse?)
guys had created translated forks of the code, which we wanted to remerge.
HTH,
Adriaan van Kessel.
Disclaimer RIVM___
computer
computer-go-boun...@computer-go.org wrote on 18-01-2010 09:21:43:
Back up a bit - what's your primary interest ? I can readily
believe that not many near blind play Go on the internet now, but
what makes you believe a properly supportive server would bring them
out of the woods, or that
computer-go-boun...@computer-go.org wrote on 18-01-2010 18:16:28:
On Mon, Jan 18, 2010 at 05:43:34PM +0100, Adriaan van Kessel wrote:
computer-go-boun...@computer-go.org wrote on 18-01-2010 11:34:52:
(ii) NNGS might be used as possible base of a modern go server.
The
obvious advantage
computer-go-boun...@computer-go.org wrote on 07-04-2009 18:33:34:
Thanks. What about linked lists?
They seem to be both compact and fast to merge and detect duplicates.
Why have you abandoned them?
Linked lists have a terrible cache behaviour: every pointer (or index)
dereference has a nearly
[EMAIL PROTECTED] wrote on 27-10-2008 14:57:54:
On 27-okt-08, at 11:51, terry mcintyre wrote:
- Original Message
From: Mark Boon [EMAIL PROTECTED]
snippage
Let me first describe what I did (ar attempted to do): all nodes are
stored in a hash-table using a checksum.
Perhaps this is also among the well-known material (or something
There have been discussions about handling symmetry in the past.
See for instance Heikki Levanto's group theoretic hashing paper.
For 'classic' (non MC) programs, board-symmetries were not important,
except for handling joseki/
Oops I confused you with Antti Huima. No offense...
I meant:
http://fragrieu.free.fr/zobrist.pdf
Sorry,
AvK
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Oops. Please ignore ...
AvK
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
A reasonable xor+shift random (similar to Marsaglia's, but only 64bit
instead of 128 bits), using the pentium's rdtsc-instrunction to add
additional entropy (i used gnu's inline assembler) :::
#define rdtscll(val) \
__asm__ __volatile__(rdtsc : =A (val))
typedef unsigned long long
The question I have is how much does RDTSC slow this down?I may do
I don't know.
If I understand correctly, rdtsc can be executed in parallen with *some*
other instructions (and places no barrier in the code), in which case
it could be executed at no additional cost (except the instruction
I would like to mention that your generator is 64 bit and the other
That is correct.
My timings (Haven't profiled yet):
WITH TSC:
real0m0.902s
user0m0.870s
sys 0m0.002s
WITHOUT:
real0m0.613s
user0m0.582s
sys 0m0.000s
That's for 100 M random numbers.
And inlining would
I Just omitted the new variable:
/**/
BIGTHING rdtsc_rand(void)
{
static BIGTHING val=0xULL;
#if WANT_RDTSC
BIGTHING new;
rdtscll(new);
val ^= (val 15) ^ (val 14) ^ new;
#else
val ^= (val 15) ^ (val 14) ^ 9 ;
#endif
return
Has anyone looked at the resultant distributions, to
Well, mine was pretty random.
Maybe a bit too random.
Changing the 14 and 15 shifts effectively cripples it.
I have not looked at sequential correlation, only at the
distribution, by binning the values into a histogram.
As far as I could see
Measurements ar pretty consistent.
Hardware:
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007
i686 athlon i386 GNU/Linux
(I didnot even know it was an athlon !)
AvK
___
computer-go mailing list
Mine:
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2800+
stepping: 0
cpu MHz : 2079.595
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
Alpha-beta gets better with increasing depth even with a random
evaluation.
http://www.cs.umd.edu/~nau/papers/pathology-aaai80.pdf
(this link is from an earlier discussion:
http://computer-go.org/pipermail/computer-go/2005-January/002344.html
)
AvK
decades it has been understood that a chess program with a better
evaluation function improves MORE with increasing depth than one with a
lesser evaluation function so it appears that Go is not unique in this
Well, isn't that trivial?
suppose, you have a perfect evaluation function, but you
I don't understand how what you describe relates at all to the study.
It doesn't.
It is a reaction to Don's explanation of it.
AvK
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
the thing that got me thinking about this is that i've never seen an MC
player really play out a ko fight. (or perhaps they are in their own cryptic
MC way that i can't see).
Well this could easily be solved by *always* investigating
moves that take (or create) a ko.
This of course will
So it's possible to create a triple-ko repetition, take that move sequence
and find
a non-triple-ko situation that uses the exact same repeated move sequence ?
I am afraid I don't follow. Please rephrase.
In my words: you have a sequence of moves (M0) leading,
to a certain position (P0).
An alternative to matching board hashes is to test for repeated move
sequences.
No. repeated position != repeated sequence.
Since one stone is added to the board with each move,
a repetition can only exist between two moves if exactly that number
of stones was captured inbetween (+- pass
I wonder if the power supply can be adapted to European 230V system. It
Without modifications, the system would centainly play at dan level.
At least: close to God.
BTW: the Fotland-article about ladders is very readable.
A must-read, even if you want to implement things differently.
AvK
There was a thread on this list, started by Chrilly,
around 30 Mar 2006:
http://computer-go.org/pipermail/computer-go/2006-March/005127.html
Note: there is an error in the 16-element table, corrected later
in the thread.
HTH,
AvK
___
computer-go mailing
happen. (without undo, that is)
Adriaan van Kessel
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I think he is betting on null move proving - but I'm real skeptical that
it will be effective in Computer Go. It will indeed reduce the tree
IMHO null-move mixes badly with ko-tactics, effectively doubling
(or squaring ? ;-) the tree size.
It might be of some use in solving local
You can use a binary tree. In each node you store the number
of child nodes in the left subtree. (maybe also for the right subtree)
If you want to handle duplicates, you could add yet another counter to the
nodes.
Finding the median is easy. As a bonus, you can also find the value
for *any* rank
... It was done as a simulated annealing.
Yep:
http://nngs.ziar.net/cgml/split/7/5/9/[EMAIL PROTECTED]
[ maybe simulated annealing is Monte Carlo as performed by
blacksmiths, after all ;-]
AvK
___
computer-go mailing list
computer-go@computer-go.org
UCT could help to tiddy up the transposition table
Erik van der Werf's thesis was mainly about
transposition table replacement algorihtms, IIRC.
My personal summary: it is very hard to be more clever
(at replacement) than always replace when hitting an occupied slot.
(this is very similar to
28 matches
Mail list logo
