I tried simulating a random walk in 3D. In the first attempt, I took 1000 random unit vectors and added them up, doing this for 100 different seeds. The result should approach the sqrt(1000), which it does - sort of.

Then to be clever, I tried populating the surface of a unit sphere with 1000 points and taking them as my vectors, with strange results. What is going wrong?

You have not a good (homogeneous) distribution of vector with first method. Mesh with ~9000 face and 5000 points. Points are far away on cardinal points.
On this image I put color with same scale representing the area of each face.

random vectors whose components are picked randomly in some cube will be very different from random vectors whose components add up to a unit vector.

Also, populate geometry specifically is not random. Each new point is picked as far away as possible from all previous points, so you’d expect the vectors to cancel out a lot more.

For me the method from populate geometry is better as it is more homogeneous. So you could use it this way. Generate n points. Pick randomly one vector from these n vectors, repeat. You will have a good random walk. But there are some components for that.
See Heteroptera

Seems to be quite a few ways to be "random’. The Heteroptera Random Direction component gives the random walk value I’d expect, but the Wolfram method is dictated more by aesthetics of even spacing., which also appear to be what Populate Geometry is trying to do, according to @DavidRutten. A random walk using the Wolfram definition also gives too low a figure for total vector length, if you’re interested in the classic random walk.

I can’t recreate what I did, but when I was playing around,at one point, the sum of the vectors was 3^1/2, which now makes some sense when you point out that the vectors came from within a cube.

Joseph, I tried your def with 1000 points and 100 trials, and kept the point on the unit sphere, as above. The total length is close to the classic random walk value,but maybe there’s some imbalance in this approach too. So far, the Heteroptera component gives the closest value. I wonder what algorithm they’re using?.

This is weird? I changed the distance/length domain to ‘0.1 to 1.0’ (to avoid zero length segments) and used 1000 points and 100 seeds. Odd that one of the seed triplets goes consistently in the X direction and another heads toward negative Z.

P.S. Going back to version ‘b’, a seed value of 210 generates the seed triplet 131, 131, 167 which for some reason, results in the polyline heading consistently in the X direction.

As well you should. It relies on the .NET random engine which is not a particularly good one. Different seeds tend to generate related sequences based on their ratios. You can clearly see this when populating a cube using seeds 1, 2, and 3 respectively for the x, y, and z components.

In grasshopper 2.0 I’ve added many more random engines and picked a better default one. Specifically, Mersenne Twister, PALF, and Xoshiro256 will be available and they are considered very good ones, although not good enough for cryptographic purposes.

It’s a rather simple, straightforward script, where initial mover positions - three-dimensional points -, get iteratively moved by random unit vector velocities. Nothing more nothing less!