Home Download Help Resources Extensions FAQ NetLogo Publications Contact Us Donate Models: Library Community Modeling Commons User Manuals: Web Printable Chinese Czech Farsi / Persian Japanese Spanish

NetLogo Models Library: 
If you download the NetLogo application, this model is included. You can also Try running it in NetLogo Web 
Partition Permutation Distribution is a model built around the idea of a partition function. This function relates between an integer, e.g., 4, and the number of different ways you can break this integer up into groups of integers, where order does not matter. For instance, 4 can be broken up in 5 ways:
(1) 4; (2) 3 + 1; (3) 2 + 2; (4) 2 + 1 + 1; and (5) 1 + 1 + 1 + 1.
Notice that in the above example, the number '1' appeared more often than the number '4.' Why is that? To address this question, this model allows you to repeatedly find partitions of a number and look at the distribution of integers in the partitions.
This model is a part of the ProbLab curriculum. The ProbLab Curriculum is currently under development at the CCL. For more information about the ProbLab Curriculum please refer to http://ccl.northwestern.edu/curriculum/ProbLab/.
In this model, you choose a targettotal, for instance 20, and the code randomly generates addends of the total and adds them to the runningtotal. These addends are represented in the view, too, as colorful lines that each are as long as the addend it represents. For instance, an addend of 13 will be 13 "patches" long ("patches" are the NetLogo square areas that make up the grid of the view). When the runningtotal reaches the total, there's been a 'success.' Unlike the actual partition function, this model will not return a value. Moreover, in this model, there is no explicit attempt to exhaust all the partitions. Instead, the randomized procedure keeps adding up the totals randomly. Over many such bruteforce addings, a graph shape emerges, and the same shape emerges both for constant totals over many runs and for different totals. The question is why this shape emerges and what this shape means in terms of partitions. So this model uses partitions as an engaging riddle to explore the idea of distribution.
Note: The shape of the graph does not correspond to a simple distribution of all possible permutations, nor to a simple scaling up of such a distribution, such as we would expect the model to create through repetition of previously created partitions. That is, it is not the case that the model chooses randomly from the set of all possible partition permutations of some total. There are two conditions for running this model, depending on the setting of the slider 'diminishingsamplespace?' The following comment refers to the case that the switch is set to 'On.'
The model chooses a first addend out of a space of the whole total, a second addend out of the space of the remainder of the total, and so on. So, the greater addends are "over represented." For instance, for a total of '5,' there is only a single partition with a single addend  the partition "[5]" that includes only '5' as an addend, whereas there are numerous partitions that do not include '5.' So you might expect that '5' would occur very rarely as compared to, say, '1.' However, due to the rationale of the model, '5' actually occurs much more often. Involved here are some subtleties and possible confusions as to what we mean by 'often'  what our unit of analysis is: Are we counting per addend or per total? Each time a total has been obtained and the model begins creating a new total, there is a 1outof5 chance that the first addend will be '5.' Another way to think of this is that you might expect the partition [5] to occur as often as the partition [1 1 1 1 1], but actually the partition [1 1 1 1 1] occurs 1/ 3125 as often as the partition [5], because we have to get a '1' AND a '1' AND a '1' AND a '1' AND a '1,' whereas for [5], all we have to get is a '5.' Understanding these subtleties may help you develop a more nuanced understanding of statistics experiments.
When you open the model, numerical and Boolean values will already be set for an easy start, as following: To begin, you can slow down the model with the 'adjustspeed' slider that is on the topleft corner of the view. TARGETTOTAL is set at 20. Press GO and watch the RUNNINGTOTAL and ADDEND monitors. The addend will be a random number between 1 and 20. Immediately, this addend, say 7, will move over to the runningtotal, and now there will be a new addend. This new addend will be a random value between 1 and 13 (because the default setting of the switch 'DIMINISHINGSAMPLESPACE?' is set so that addends are chosen from the difference remaining up to the total). Say the second addend is 2. So now the runningtotal becomes 9. The third addend could be 5, so we'd get 14, and so on. Let us say that this run gave us the addends 7 + 2 + 5 + 1 + 4 for a total of 20. The histogram grows one notch up for each of these addends.
Switches: WAITATFULL? If it is set to 'On,' the experiment will wait briefly each time the targettotal has been achieved. DIMINISHINGSAMPLESPACE?  if 'On,' addends will be selected from a sample space that is the size of the remaining difference to the targettotal. For example, if the running total of the current addingup is at 16 and our targettotal is 20, then the next addend will be selected from the range 1thru4. However, if the switch is set to 'Off,' then the range will always be the targettotal, 20.
Sliders: TARGETTOTAL  sets the total towards which the program will be adding up the randomly generated values NUMSUCCESSES  sets how many times the program will sum up to the targettotal you have set
Monitors: RUNNINGTOTAL  shows how far towards the targettotal the adding has gone ADDEND  shows the current value that has just been generated and added to the runningtotal SUCCESSESSOFAR  shows how many times the total has been reached. Once this is equal to the NUMSUCCESSES slider value, the program stops. MEAN #ADDENDS PER TOTAL  shows how many acceptable addends it took, on average, to fill the targettotal that you set, over all the trials PREVIOUS LIST OF INCLUDED ADDENDS  shows the last completed series of addends up to the target total
Buttons: SETUP  initialize variables GO  run the model under your chosen settings. It will run through as many 'numsuccesses' as you have set. ADDONCE  A single addend is added to the runningtotal and the histogram is updated. Use this to run the program step by step.
Plots: ADDENDS  plots the addends as they are randomly selected #ADDENDS PER TOTAL  plots the number of addends it takes to complete each targettotal
When 'diminishingsamplespace?' is set to 'Off,' the addends get smaller as you get closer to the total.
The histogram columns get smaller as you move from left to right.
When 'diminishingsamplespace?' is set to 'Off,' the 'mean addends per total' value converges to the value of 'targettotal.' Why is this so? Also, the 'Addends Per Total' distribution slopes down to the right. What can you say of that?
When 'diminishingsamplespace?' is set to 'On,' the 'mean addends per total' value converges to some value. Can you say anything about this value in relation to other settings in the model? Also, the 'Addends Per Total' distribution is normal. Why is that?
Set the targettotal to .5. Run the model over many numsuccesses, 'diminishingsamplespace?' set to 'On,' and with a high targettotal. The 2column will be 1/2 the height of the 1column. The 3column will be 1/3 the height of the 1column. The 4column will be 1/4 the height of the 1column. The 5column will be 1/5 the height of the 1column. etc. So we get a '1/n' function. Why is this? Does is work for other targettotal values?
Another way to express this relation between the columns is as follows. Say we look at Column 'i.' The relation between the height of Column i and the column immediately to its left (Column 'i  1') is (i  1) / i . For instance, the relation between the heights of Column 9 and Column 8 is that Column 9 is 8/9 as tall as Column 8.
Set targettotal to 2 and 'diminishingsamplespace?' to 'On.' Set 'numsuccesses' to 10,000 and run the model until it stops. Compare the value of 'Successes So Far' to the yvalue of the 1Column in the "Addends" plot. You will see that these values are very similar. So over many runs, we expect that the '1' will occur as many times as we have had runs. (See ProbLab model 'Expected Value' for an explanation of how to make predictions of expected values.) This is true for other targettotals  we chose 2 so as to make this work fast.
Now look at the 'mean #addends per total' you received. It should be very near to 1.5. This is related to our finding, above, that the 2Column is 1/2 (.5) as tall as the 1Column and to our expectation to get as many '1's as we have had successes. These ideas combined suggest that we should get .5 as many '2's as we have had successes. So the 1Column and the 2Column together are 1.5 as large as the number of successes. This means that there are about 1.5 addends in each total. For the case of a targettotal of '3,' we'd need to add '1 + 1/2 + 1/3.' So we'd expect a mean of 1.833 addends per toal. Try this, too!
Add a monitor that shows the minimum, average, and maximum number of partitions in every run (the number of items is the length of theshortlist). Add plots for these values. What shape do you expect this distribution to have? Will the values change per targettotal?
Note that currently we are using this logic:
set addend ( 1 + random tempsamplespace )
This means that the model chooses addends with an eye to how much space is left up to the total (tempsamplespace is the difference between the running total and the target total). If we removed this, and only asked for "random total", how would the model change, if at all? How would the above extensions change, if at all?
Note that in the above line of code, we set the addend to "1 +...etc." This is due to the nature of the 'random' reporter. The command 'random 3' returns numbers between 0 and 2, and will never return the number 3. So by adding 1, we get the values we actually want. You will come across this often in NetLogo, such as when working with lists. For example, if we had a list named "friends" ["pat" "bob" "joe" "kate"], the 3th value, 'joe,' is called "item 2 friends."
This model is related to other models in the ProbLab suite. Like other models, it looks at the evolution of a distribution that reflects procedures that have random elements. However, unlike other models, the distribution here is never bellshaped. The greatest learning gain expected to come from working with this model is in comparing it to other models in ProbLab. This comparison should in particular revolve around an articulation, possibly in general terms, of what precisely about this model makes a bellshaped distribution unlikely.
This model is related in an interesting way to 9Block Stalagmite. In that model, the distribution of permutations reflects the sample space of all possible permutations. But in this model, the distribution does not reflect the sample space directly (see introduction, above).
Also, the model is related to the AttemptsUntilSuccess histogram in Prob Graph Basic and to the Distances to Whites histogram in Shuffle Board. Actually, those two histograms behave similar, whereas the histogram in this model behaves differently. Understanding this difference may sensitize you to "graph families." Just because all these graphs decrease monotonously, it does not necessarily mean that they describe the same or related functions.
This model is a part of the ProbLab curriculum. The ProbLab Curriculum is currently under development at Northwestern's Center for Connected Learning and ComputerBased Modeling. . For more information about the ProbLab Curriculum please refer to http://ccl.northwestern.edu/curriculum/ProbLab/.
If you mention this model or the NetLogo software in a publication, we ask that you include the citations below.
For the model itself:
Please cite the NetLogo software as:
Copyright 2004 Uri Wilensky.
This work is licensed under the Creative Commons AttributionNonCommercialShareAlike 3.0 License. To view a copy of this license, visit https://creativecommons.org/licenses/byncsa/3.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Commercial licenses are also available. To inquire about commercial licenses, please contact Uri Wilensky at uri@northwestern.edu.
This model was created as part of the projects: PARTICIPATORY SIMULATIONS: NETWORKBASED DESIGN FOR SYSTEMS LEARNING IN CLASSROOMS and/or INTEGRATED SIMULATION AND MODELING ENVIRONMENT. The project gratefully acknowledges the support of the National Science Foundation (REPP & ROLE programs)  grant numbers REC #9814682 and REC0126227.
(back to the NetLogo Models Library)