[Haskell-cafe] Re: Zippers, Random Numbers & Terrain

[Chung-chieh Shan]

Thomas Conway <drtomc at gmail.com> wrote in article <784a62100708011620n40394375m5ffe46acb2da0ca1 at mail.gmail.com> in gmane.comp.lang.haskell.cafe:
> On 8/2/07, apfelmus <apfelmus at quantentunnel.de> wrote:
> > That concludes the infinite terrain generation for one dimension. For
> > higher dimension, one just needs to use 2D objects instead of intervals
> > to split into two or more pieces. For instance, one can divide
> > equilateral triangles into 4 smaller ones. In fact, it doesn't matter
> > whether the starting triangle is equilateral or not when using the
> > midpoints of the three sides to split it into four smaller triangles.
> Nice.

Nice indeed!  The infinite binary tree of the terrain intervals
reminds me of the hyperbolic plane, of course, and its use in
arbitrary-precision real arithmetic (cue a real mathematician).

> The issue of the RNG running backwards was what made me realize
> that rather than using StdGen in the nodes, if you simply number them
> (Hmmm - the nodes are countably infinite :-)), you can then [e.g.] use
> a cryptographic hash or similar to turn them into random numbers. You
> can seed the hash to generate different terrains.

Isn't the whole point of a good RNG that running it forwards and
backwards should be statistically the same?

> You may be interested that in some of the code I wrote for the right
> angle isosceles triangle case, I got into precision problems. [...]
> After pondering on this for a while, I realized instead of
> representing the scale of the triangle as a Double, I could use
> (Either Double Double), with Left x representing the scale x, and
> Right x representing the scale x * sqrt 2 / 2. That way, all the
> rounding problems can be made to go away. Well, not all of them -
> after all Double has limited digits of mantissa, but down to quite
> small scales, the arithmetic will be precise. Actually, you could use
> (Either Rational Rational), except that performance would be [even
> more] atrocious.

What about a possibly infinite list of binary digits in base sqrt(2)?
Surely the beauty would overshadow any performance problems. (:

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
"Elegance is optional." -- Richard A. O'Keefe