Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Since `random(x)` returns a random number in [0,x), it will always output a number that is less than `x` (the initial value of x is 1 in this case). Therefore, the outcome where repeated applications of `random(...)` to its own result has little shrinking effect is vanishingly small. It's the result of these repeated applications that is being subtracted from the length of the unit vector that is used to position each pixel. So the pixels naturally accumulate around that unit length. No broken crypto here.

It's sort of like asking, "What would happen if I multiply a bunch of numbers together that are guaranteed to be less than 1 (and even much less than 1 much of the time)?"



In more formal terms, since it is a uniform distribution you can write

  random(x) = random()*x
then you can easily see that

  random(random(random())) = random()*random()*random()
The resulting distribution is not equal to random()^3, because e.g. the probability that all 3 random calls give you a number <0.5 is only 0.125.


Oh. Thanks for the explanation, but I thought random was taking a seed, which would have made this much cooler, like this:

https://www.jstatsoft.org/article/download/v007i03/892


It depends on the language, some languages like JS does not take an argument. So, it is language-specific.


Clear and simple explanation


Took me a moment to understand that by random()^3 you meant the output of the random function to the power of 3, not some temporary function which we name "random^3" since that's also how we build it.


Exactly, like Perlin noise, the output is not indicative of the function. Works as intended. The beauty is in the fact that when using pseudorandom number generation and the right output function, you can simulate a lot of things. Star systems, planets, stock market games, aim handicap, and itano circus.


That's how many computer games generate their universes. It's called procedural generation [1].

One of the earliest and most famous examples is Elite [2]:

> The Elite universe contains eight galaxies, each with 256 planets to explore. Due to the limited capabilities of 8-bit computers, these worlds are procedurally generated. A single seed number is run through a fixed algorithm the appropriate number of times and creates a sequence of numbers determining each planet's complete composition (position in the galaxy, prices of commodities, and name and local details; text strings are chosen numerically from a lookup table and assembled to produce unique descriptions, such as a planet with "carnivorous arts graduates").

[1] https://en.wikipedia.org/wiki/Procedural_generation

[2] https://en.wikipedia.org/wiki/Elite_(video_game)


Procedural generation was also used to generate levels in the Pitfall game for Atari 2600. A single level was represented with a byte (!) and bits were controlling the number of rolling logs, holes, etc. There were 255 levels there and LFSR was used to go from one level to another, so the actual level bytes wasn't even stored in the ROM.

For more details and screenshots see this great blog post: https://evoniuk.github.io/posts/pitfall.html


Elite: Dangerous and Elite Dangerous: Odyssey - the latest versions of Elite - still use procedural generation in order to generate each one of the 400 billion star systems in their shared galaxy.

The proc gen is also consistent and persistent, based on some initial seed value decided upon at some point in the game's genesis; A CMDR who jumps their ship to some star system never visited before has that star system generated by their game client according to its algorithm - all the system bodies and their types and classes and whatever's on any planets, if anything.

Another CMDR who subsequently visits it will see the same thing the original CMDR saw.

It's a thing of beauty.


I urge anyone who has played the original Elite but not Elite: Dangerous to please go do that. The game is amazing, beautiful and an absolute treat if that type of gameplay is what you want. It's even better in VR but playing in an environment where you can't see the keyboard makes a HOTAS mandatory instead of recommended.

I am not joking when i say that E:D is in my top 3 games of all time.


I know, I wrote a procedural universe simulation in 2006. It’s like playing god.


> No broken crypto here.

Which implementation of random is processing using? There's a lot of random() implementations that aren't suitable for crypto (like JavaScript and Java).

1. https://docs.oracle.com/javase/8/docs/api/java/security/Secu...

2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


Good point. I should have said, "No evidence of broken crypto here."




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: