The Fragile Sphere

At some point I felt the urge to model everything described above in software. Back in those days I worked mostly in Scala. But writing code in only one language gets tiresome.

It seemed to me that Python — far less popular then than it is now — held enormous potential. First and foremost, I was driven by the simple prudence of a commercial developer. I wanted to get to know this curious language more deeply before it became the language of first choice for a well-known class of problems. I sensed the coming fashion for Python development and wanted to gain experience with the language ahead of time.

In particular, I was interested in seeing how Python handles large-scale graphs. I installed NetworkX, opened PyCharm, and began to experiment.

Spending two to four hours a day on the project, over the course of several weeks I built a heavily simplified but working software model of the nonsense I described earlier.

The model was a spherical surface made up of a tangled multitude of edges. These edges connected numerous nodes to one another.

Each node represented a single economic actor. The edges depicted the connections between them.

Every edge possessed a "mass." This "mass" strove to tear the connection apart. The "mass" depended only on the length of the edge. The connection "wanted" to fall toward the center of the sphere. That was the direction in which the vectors of the edges' "masses" pointed.

What kept the surface from collapsing inward upon itself was the "elasticity" of the edges that composed it. Each connection behaved like an elongated, springy straw — the more elongated, the more brittle.

Elasticity was determined by the connection's "input number." The meaning of the "input number" is easier to grasp if you imagine it as the money flowing into the connection. The connection possessed "greed." "Greed" determined the difference between the connection's input and output numbers. Greed could be either positive or negative. That is, a connection could give away either more or less money than it received. If the amount of money in a connection dropped sharply, the edge turned from a straw into a thin string, thereby increasing the probability that the entire surface would rupture.

"Greed" depended on a savage multitude of parameters. For example, on the length of the connection (the longer the connection, the greater its "greed"), on the "input numbers" and "greeds" of the surrounding connections, on proximity to the root of the graph's branching, and on various other things. But among the parameters shaping a connection's "greed" there was also a random component. That is, every edge of the spherical network carried within it a tiny "bomb of uncertainty." A connection's greed could randomly fall or, conversely, rise. A rise in the level of greed was the more probable.

If a connection's mass exceeded its "elasticity," the connection ruptured. Money flowed to where it was cheaper. New connections arose if the difference between the output number of the "donor" connection and the input number of the "acceptor" was large enough to give the connection an elasticity compatible with life. "Open" connections at the outer ends of the graph kept branching until they ran into another graph. If such a connection, with an output number close to zero, found itself near a "rich" connection of another graph, the two joined together. The recently "null" connection became "rich" and capable of spawning new branches. I called this class of events, to myself, "commercial luck."

The model consisted of six graphs. The branching sources of two of them were located at the poles of the sphere; the remaining four I distributed evenly along the equator. The input number at the branching sources I made constant. This simplification made it easy to solve the problem of money "running dry" within the system. The money was not supposed to run dry. After all, in the real world it never runs dry… Or rather, money may run dry in our pocket, but not in the whole economic machine.

If a connection's elasticity became less than its mass, the connection simply vanished. As a rule, this led to the collapse of the neighboring edges. I deliberately placed a multitude of constant coefficients into the model so that it could be easily balanced by hand.

The resulting sphere modeled the better part of the economic effects I spoke of above. For instance, any recursive connection — that is, a ring of edges that had formed, around which "money" ran in a circle — broke fairly quickly, since the money trapped inside it was swiftly drunk dry by the "greed" of the connections composing the ring.

Some things, however — for example, the rise-in-brittleness effect created by the complex products needed to manufacture simple ones — had to be implemented specially, using additional properties and rules.

This whole system ran on a timer. It changed iteratively, once every so many milliseconds.

I made a software sphere with a very complex and constantly changing surface. Hypothetically, this surface could "crack." In some local region of the surface, connections would periodically rupture, sharply and in an avalanche.

The first "crack" always triggered the further rapid destruction of the surface. It was precisely the appearance on the surface of a "crack" critical to the system's stability that corresponded to the "fragility threshold" from my earlier reasoning.