[computer-go] Decision-making methods in a distributed "swarm" of "light-weight" processors.

Aidan Karley aidan_karley at mail.ru
Sat May 27 06:03:56 PDT 2006


In article <F61A0CFA-5776-48BC-82E8-FD58F9FCF0AF at schraudolph.org>, Nic 
Schraudolph wrote:
> > This would be interesting, were it true.
> > As one who has had actual experience keeping bees, however, I am  
> > skeptical.
> > Wherever the new queen lands (actually, sometimes it is the old  
> > queen who is
> > driven out of the existing hive by the usurper) is where the other  
> > bees land.
> 
> Muddled as it was, the article clearly did not describe where a swarm  
> clusters
> after leaving its old hive (which as you say is straight "follow the  
> queen"),
> but the process by which a clustered swarm subsequently reaches a  
> collective
> decision where to hive. That can take several days.
>
       There was a reply that hit one of my spam filters (and thus 
evaporated into information vacuum)?
       
       While apiculture is, I'm sure, interesting, I posted the links 
because I was interested in the search-and-re-probe algorithm that 
appears to be in use for determining which of the numerous potential 
permanent sites is the "best possible" site for the second phase of the 
relocation. If I've understood the (irrelevant) apiculture correctly, the 
swarm leaves the old nest /en masse/ , and possibly "in a hurry", moves a 
distance and makes a temporary bivouac encampment. From the encampment, 
scouts are sent out to explore the environ into which they've flown 
(sense: flapping, and sense: escaped) and here they execute a 
"consensus-quorum" search algorithm to locate the optimal site they can 
reach from the bivouac. "Optimal" for the purposes of long-term 
settlement, rather than another bivouac.
       The combination of multiple, simultaneous, *simple* evaluations 
going on, with the repeated visitation of a site by a scout made me think 
of the process of re-evaluating the possible moves from your "move 
generator" for playing Go.
       Is this sort of algorithm (I'm afraid you'll have to read the 
article - I'm fuzzy enough to not trust myself to describe it accurately) 
known and used in computer go? Could it be useful?
       
-- 
 Aidan Karley,
 Aberdeen,  Scotland
 Written at %DATETIME%, but posted much later.

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?





More information about the computer-go mailing list