Your solution would still be way faster, as I still have to generate a
new random number every time I need one.
The "problem" is lack of side effects in Clean. If I stick to functional
programming paradigm -and that is the whole point of my effort- I can't
write function which returns a different number each time it is called.
A function is supposed to return same result every time it is called
with same parameters so I can't/shouldn't write an analogue of
getNextInt() (whether or not getNextInt() returns a number from a list
or from a random number generator.)
I just shaved off time by not initializing a new random generator each
time a node is visited. Instead, when a leaf node is visited, first
maxMoves terms of random list is sent to MC evaluation, and remaining
terms are used to create a new list. Sharing this list across whole
search tree would be ugly and complicated. So I still initialize a new
random list for each new tree node but reuse it for subsequent MC
evaluations from that node.
Berk.
Imran Hendley wrote:
A sorry about that. Glad to hear you fixed the problem. What was your
solution?
It seems you mentioned the "global list" approach in your email which
I missed too. Why did you think this was an ugly approach? I just put
my random array in a Singleton object (call it
MyRandomNumberGenerator) which internally stores the next index and
has a method for getting the next random number. So I just replace all
my calls to Random.getNextInt() with
MyRandomNumberGenerator.getNextInt(). Actually I can see how a lot of
people would still call this ugly... But it's just a lookup so I think
it will beat any other solution that involves generating a new random
number by a reasonable margin.
On Dec 19, 2007 5:15 AM, Berk Ozbozkurt <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
That was not the problem, as the source code is available and it
doesn't
call system libraries at all. I was initializing with known seed in my
tests anyway.
Thanks though, in the process of composing a reply demonstrating the
problem, I found a partial solution. Now random number generation
takes
3% of running time, compared to 60% of older version and ~1% of a
hypothetical ideal solution.
Berk.
Stuart A. Yeates wrote:
> Probably the reason that it is so slow is that it's aiming for a
> cryptographically random number sequence. These are usually derived
> ultimately from kernel timings (often via /dev/random on linux
> systems) and it can take a while to establish a degree of confidence
> in the randomness of these bits.
>
> If you want a sequence of numbers that is very unlikely to
repeat but
> that doesn't have to be cryptographically random, standard
practice is
> to initialise the random number generator with the current time
> (usually a long expressed in milliseconds). This naturally fails if
> you ever create more than one sequence per millisecond.
>
> cheers
> stuart
>
>
> On 19/12/2007, Berk Ozbozkurt <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>
>> Hi,
>>
>> I'm currently writing a UCT based go program in Clean to see if
it is
>> feasible to write one in a functional language. This is my
first attempt
>> at functional languages, and I'm having trouble with random
numbers.
>>
>> A mersenne twister module is available for Clean. Once
initialized it is
>> reasonably fast to extract a new random number from the generator.
>> However, it is about a hundred times slower to initialize it
with a new
>> random seed. Therefore my first attempt at generating random
numbers by
>> storing seeds at tree nodes and creating a new random list and
a new
>> seed each time random numbers are required for mc evaluation is
very
>> slow. The alternative seems to be passing around an index to a
global
>> random list, which is both ugly and complicated. Is there
another way?
>>
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
