Wed, 25 Jul 2007

On Tue, Jul 24, 2007 at 09:37:57PM -0400, Kragen Javier Sitaker wrote:
> On Sat, 31 Mar 2007 09:56:28 +0200, Eugen Leitl wrote:
> > Great stuff, as usual. I wouldn't make all the initial IDs random.
> > Reason: you can e.g. set the MAC from a WGS84 GPS position fix
> > (about /m^2 Earth surface resolution, IIRC). Ideally, the ID should
> > be a real 3d coordinate, of course.
> 
> Sure, it might turn out that embedding GPS receivers in every munchkin

Not in every node. Nodes with GPS-initiated address would be
authoritative, and be nuclei of growing domains. This makes the network
converge quicker, and the emerging address scheme is actually
tied to an established grid.

> is cost-effective, but it also might turn out that it's not.  Right
> now they seem to command a considerable price premium, in the tens of
> dollars --- about one and a half orders of magnitude greater than the
> price for an entire munchkin.  I don't have any idea whether radio
> receivers' costs will start to obey Moore's Law, but I don't have
> strong reasons for thinking they will.

I agree. The munchkin network will kill GPS, at least in high-density
areas. There's no competing for multiple strong beakons vs. few
very weak high above.
 
> > I wouldn't also limit this to just direct neighbours, a node can
> > sometimes see quite far -- but you'd get other distance metrics,
> > such as signal strenght or a relativistic pingpong measurement.
> 
> Indeed, I was only starting with a grid and eight neighbors because I
> figured that if the approach would work anywhere, it would work there.
> 
> While visiting Darius Bacon a couple of weeks ago, it occurred to me
> that, at least for a regular two-dimensional grid, an Ising spin glass
> simulation (per bit position) is probably the right thing --- it can
> evolve arbitarily large domains in relatively few iterations.

That's the right idea.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

Tue, 24 Jul 2007

On Sat, 31 Mar 2007 09:56:28 +0200, Eugen Leitl wrote:
> Great stuff, as usual. I wouldn't make all the initial IDs random.
> Reason: you can e.g. set the MAC from a WGS84 GPS position fix
> (about /m^2 Earth surface resolution, IIRC). Ideally, the ID should
> be a real 3d coordinate, of course.

Sure, it might turn out that embedding GPS receivers in every munchkin
is cost-effective, but it also might turn out that it's not.  Right
now they seem to command a considerable price premium, in the tens of
dollars --- about one and a half orders of magnitude greater than the
price for an entire munchkin.  I don't have any idea whether radio
receivers' costs will start to obey Moore's Law, but I don't have
strong reasons for thinking they will.

> I wouldn't also limit this to just direct neighbours, a node can
> sometimes see quite far -- but you'd get other distance metrics,
> such as signal strenght or a relativistic pingpong measurement.

Indeed, I was only starting with a grid and eight neighbors because I
figured that if the approach would work anywhere, it would work there.

While visiting Darius Bacon a couple of weeks ago, it occurred to me
that, at least for a regular two-dimensional grid, an Ising spin glass
simulation (per bit position) is probably the right thing --- it can
evolve arbitarily large domains in relatively few iterations.

Sat, 14 Jul 2007

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 27184 bytes
Desc: not available
Url : http://lists.canonical.org/pipermail/kragen-hacks/attachments/20070715/7ef68ff2/attachment-0001.png

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 27184 bytes
Desc: not available
Url : http://lists.canonical.org/pipermail/kragen-discuss/attachments/20070715/7ef68ff2/attachment-0001.png

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 27184 bytes
Desc: not available
Url : http://lists.canonical.org/pipermail/kragen-tol/attachments/20070715/7ef68ff2/attachment-0001.png

Tue, 10 Jul 2007

An HTML attachment was scrubbed...
URL: http://lists.canonical.org/pipermail/kragen-tol/attachments/20070710/bf6a1161/attachment.html