[Haskell-cafe] Re: Zippers, Random Numbers & Terrain
ccshan at post.harvard.edu
Thu Aug 2 01:30:18 EDT 2007
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 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
More information about the Haskell-Cafe