Output number/size of graph components

[divilian]

When param_sweep.jl is executed, include among the output written to files the sizes (in # of agents) of each graph component.

(Probably in same file as produced by #39.)

[venkatachalapathy]

http://juliagraphs.github.io/LightGraphs.jl/latest/pathing.html#LightGraphs.connected_components

has answers. Pinged Will about this on slack.

[divilian]

Hey @venkatachalapathy, we need to figure out what is the best way to represent the component sizes in the simulation output. The way we're doing it now isn't the right way, but it's unclear to me exactly what the right way is.

The issue is that each simulation run produces a variable-size array of component sizes; e.g.:

[ 17, 5, 3, 3, 2, 1, 1 ]

which, in this example, means that in addition to the giant-ish component with 17 nodes, there is a component with 5 nodes, two other components with 3, etc.

This doesn't "fit" well in a .csv. Currently we're outputting:

λ,seed,gini,Agents_per_component,Number_of_components
1.0,1234,0.4226625884863773,Any[7 2 2 1 2 1 1 1 1 1 1 1 2 3 1 1 1 1],18
1.0,1235,0.4287756544659061,Any[3 13 1 2 1 2 1 1 1 2 1 1 1],13
1.0,1236,0.4257860898656544,Any[2 5 10 1 2 2 1 1 1 1 1 1 1 1],14
...

which I imagine is useless for analysis/stats/plotting.

Probably the right approach is to figure out what aggregate thing(s) we actually want to analyze, and store those instead of all the raw component sizes. Maybe it's one or more of these:

• the size of the giant component
• whether or not there is a giant component, according to some threshold
• the fraction of agents that are in the giant component
• comparison stats like "mean wealth for agents in the giant component, vs. those not in the giant component"
• etc.

Let us know your thoughts. As of now, the *simulation_results.csv file(s) will have the unusable format above.

[wkneh]

Fixed by mistaken comment referencing issue #41.