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/
> 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/ fus
Oops. Please ignore ...
AvK
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Die tweelingen van hetzelfde geslacht kan ik weinig aan doen.
(voorletters "bestaan niet": er moet op de volledige voornamen worden gezocht)
Ik vrees dat de meeste kinders meer dan een voornaam hebben.
Eventueel zou ik ze nog op de door jou aangeleverde roepnaam kunne zoeken
. Anders wordt het nood
> 01010101010101010101010101010101
>
>
IMHO they are exactly the same and should be as such.
At the start of every simulation (before a 0 or 1 is reported)
, the situation is (should be) exactly the same.
So there is no difference w
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
coma_
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
computer-go@computer-go.or
> 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
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
> 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
> 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
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
> 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
___
> 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/
> 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
> 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 fo
> if (move[n-1]==move[n-7] && move[n-2]==move[n-8] && move[n-3]==move[n-9] &&
> move[n-4]==move[n-10] && move[n-5]==move[n-11] && move[n-6]==move[n-12])
I think comparing a full-board hashvalue to all previous positions *with the
same amount of B/W stones* is cheaper.
Your formula is incorrect,
> 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). A
> 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 move
> 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
> "(compressed) bitmaps". You don't just keep a sorted list?
With (compressd) I mean that (most of) the bitmaps are relatively
sparse. For an isolated stone, the needed size only needs to be about
((2*19) +1) / sizeof(bitmap_element), ~= 2 or 3 32bit ints.
By skipping the leading and trailing zeros
> Yep, I think I had a bug. I just removed an optimization that I
I just checked your array, and found that {14 56 383 3047} --> 3500 --> 875,
which is also in the array. Back to the old drawing board.
BTW I don't get this pseudo-liberties - stuff.
Maintaining a list of members + a list of libert
> 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" sub-probl
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
h
> No it wasn't. I think you're confusing me with Dennis Breuker.
I stand corrected.
> Yes, "new" does quite well
At least I remembered the conclusion.
Remembering the Authors name should be next on my list...
AvK
___
computer-go mailing list
computer-g
> 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
