Random Walk

I am trying to write code that uses a random number to take either one step forward back or even stay still. I am having problems with generating the correct step length. I use the table to command to have 20 steps but each increment of the random function makes the step length go up! This is what I have

x = Table[RandomInteger[{-1, 1}] i, {i, 20}]

How can I make this so I can keep the random number values constant while increasing the number of steps in one direction?

Your on the right track, Megan. It is the “i” in the computed value in Table that multiplies each step by the iterator value. RandomInteger produces the step all by itself.
Best,
David

(* steps of -1, 0 or 1 *)
steps = Table[RandomInteger[{-1, 1}] , {i, 20}];

(* plot them *)
ListLinePlot[steps]

(* plot the distance from home at each step *)
ListLinePlot[Accumulate[steps]]

Perhaps something like this?

walk=
Module[{randoms},
 randoms = Table[RandomInteger[{-1, 1}] , {i, 20}];
 Accumulate[randoms]
 ];

The set or random numbers (note that there is no factor of i as there was in your original code) gives the instructions on what to do at each step. The Accumulate function then produces a running sum of how far the walker has gone at that step.

Visualize the walk (in the y-axis direction) using something like

ListPlot[walk]

Awesome! Thanks guys. I think what was holding me back was just not knowing the right command.

If you wait long enough, every drunkard will stumble back home. :wink:

I am not drunk… It’s only that I’ve only just gotten my mornign coffee…

this is not quite right. i assume you (i mean the drunk) starts at home because you say ‘return’ and, the probabiity of returning home (btw - this is called the return to origin problem) is 1 in one and two dimensions but < 1 in 3 dimensions. and then there’s the ‘drunk looking for his/her keys under the lamp post’ phenomenon which has not been subject to definitive computational analysis to my knowledge (there have been some experimental studies but unfortunately, the researchers tend to forget or misplace the results. perhaps they should look under a lamp post for their lost data).

Just a point on efficiency for large number of steps - you do not need Table with RandomInteger:

In[1]:= RandomInteger[{-1, 1}, 10^7]; // AbsoluteTiming
Out[1]= {0.066922, Null}

In[2]:= Table[RandomInteger[{-1, 1}], {10^7}]; // AbsoluteTiming
Out[2]= {0.599412, Null}

ListPlot[Accumulate[RandomInteger[{-1, 1}, 10^5]]]

Yes! This is an important point that I should have remembered. Generally if a function has a form with an iterator you should use it to generate a list of results rather than embedding the one-off function within Table or similar constructs. You will gain one or more factors of 10 when you do this.

this is very nice. WL is sometimes accused of being ‘slow’ when it’s really just a matter of using the right expression (the problem is how is one to know what is most efficient except by experimenting) . btw - it is adviseable when comparing expressions that involve random number generation to use SeedRandom.

another point - when comparing two programs that ‘do the same thing’, be aware that one program might run faster than the other for certain parameter values (e.g the size of the game board and number of time steps in the Game of Life) but for other parameter values the relative speeds of the two may change. i don’t understand why this happens but i assume it’s because some built-in functions offer more than one algorithm and WL decides which one to use (i’ve heard that Sort has mergesort and bubblesort and perhaps other kinds of sorting mechanism). if this is true, then there can be changes in speed as one ‘scales up’.