A Programmer's Guide to Many Worlds Lines

by John McFnordland, Exerr University

(Originally published in Spring 2000 issue of JOAC.)

(Editor's Note: The spring issue of JOAC is often the "April Fools" forum for academics that need to express their playful, but often buttoned down right hemispheres. Of course, with a topic as deep and esoteric as the Q-Ching, it's frequently the case that the line between profound and frivolous is a moving line. Such is the way of a Wise One. This is generally the situation with John anyway. We can never tell the difference between his serious scholarship and his impish side, all the more reason to publish his articles.)

Abstract: A new form of oracle based on a novel kind of interactive hexagram is developed. This model, called "Many Worlds Lines", allows the user to interact with a hexagram to produce alternative readings. This model winds up being a stepping off point for looking at "machine instructions" for oracular computers.

This article is a further development of some ideas presented in my previous paper on HyperEmblematic Lines (see McFnordland [1998]), particularly the notion of an "interactive oracle" based on "many worlds lines" that I mentioned as a route for further research. I propose to expand the idea of "moving lines" once again, showing how it could form the basis for the machine code of a primitive oracular computer. While this presentation is speculative and not based directly on tradition (at least as current scholarship has recreated this tradition in a limited fashion), it may provide some insight into what the priests at the Oracular Temple were attempting to accomplish.

Please note that this is a "working paper" on research in progress and does not conform to the usual standards of rigor common in the field of sacred mathematics. However, I felt that these preliminary results were already so exciting and promising that they must be communicated as is. I would like to thank Mike McCormick for the many enlightening discussions we had that went into this study.

Heuristic Overview of Many Worlds Lines

First of all, as will become obvious in short order, we are creating a new programming language, albeit a very simple one. As is the custom, we will abbreviate the name "Many Worlds Line" with the acronym MWL 1.0. (My students generally pronounce this acronym as "mawl", though some refer to it as "mewl" or "mule", perhaps a reference to their professor.)

As discussed in my paper on HyperEmblematic Lines, the categorization of basic yin and yang lines into "static" and "moving" can be easily extended in many directions. There was a basic paradigm shift presented in that paper, mainly that this simple binary static/moving distinction can be supplanted by a more robust generalized description of "how does this line move?" In fact, a hyperemblematic line is an encoded description of how the individual movements at each step over time contribute to the entire "journey" of the line over the course of the sitation at hand. It gives a multi-faceted and more detailed view of the situation and how it evolves than regular emblematic lines can achieve.

However, as was noted at the end of the paper, these journeys are still strictly deterministic. Even though there are many "decision points" along the journey where it is possible to make choices that could affect further outcomes, the Q-Ching has no means of representing "alternate outcomes", even with hyperemblematic lines. The hexagram may indicate that action or caution is advised, but regardless of how the querent behaves, the final outcome or hexagram is always the same. It would be useful to be able to pose alternate sequences of choices to the oracle and get its advice on all the possibilities.

In quantum mechanics, this idea of "alternative outcomes based on choices" is known as the Many Worlds Interpretation of QM. As proposed by Hugh Everett in 1957, this was a clever solution to the "collapse of the wave function" problem of QM. In a nutshell, Everett suggested that with each choice an observer makes, the universe "splits" into 2 or more alternative universes (one for each value of his choice) that proceed to evolve in parallel and independent of each other. These alternative universes form a huge branching tree structure of alternate possibilities reaching all the way back to the Big Bang. Through his choice, the observer decides moment by moment which universe he will "live in" (which leads to questions of how consciousness interacts with matter). Unlike the old Newtonian paradigm of the "clockwork universe", the future is not written in stone.

We would like to imitate this many worlds model in the Q-Ching itself. In this way, the journey of each line, as well as the hexagram as a whole, can be dependent on choices made by the querent as the interpretation proceeds. In fact, the hexagram could be "backed up" and run through its journey with a different set of choices, leading to a different sequence of outcomes. The reading becomes fluid and interactive, allowing the querent to look at many options for a single situation. The behavior of such a line over time, based on factors like the current state (yin or yang) of the line and choices made by the querent, is essentially a baby computer program. Yin and yang finally meet zero and one head on. What is amazing is how easy it is to pull this off!

Oracle Op-codes

As a stepping off point, let's quickly examine the "programming language" of hyperemblematic lines (HL). An HL is essentially a stack of n basic yin/yang lines, where n is a power of 2. This stack of lines is "compiled" or translated into a similar stack of lines called the "journey" of that line. The state of the HL at time t is read out of the journey by examining the state of the t-th line from the top of the journey. In effect, the journey is a sequence of one bit instructions, either "change to yin" or "change to yang". These instructions are completely unconditional, depending neither on the previous state of the HL nor on any user interaction.

When we move to many worlds lines (MWL), the program still consists of a sequence of instructions, but the instructions for each step of the journey are more complicated (because they are now dependent on certain inputs). In the 1.0 version, we've incorporated two kinds of inputs: the current state of the MWL (yin or yang) and an optional "choice" by the user (essentially a yin or yang decision or a "pass"). This gives a total of 2 * 3 = 6 distinct input conditions, each of which could have a separate yin or yang value for the new state of the line. This will be represented either as a sequence of 0's and 1's in parentheses, e.g., (010011), or in the standard calligraphic notation of a stack of 6 broken or straight lines. Either way, each instruction is a basic hexagram.

Unlike the HL instructions (2 operations, "make yin", "make yang") which don't depend on the current state of the line, MWLs add two more operations that are dependent on the current state ("do nothing", "change to opposite state"), for a total of 4 operations that require 2 bits (basic lines) to describe. In particular, given an operation (xy), where x and y have a value of either yin=0 or yang=1, the line for x says "If the line is already yin, make it x", while y says "If the line is already yang, make it y". Therefore (00) is "make yin", (01) = "do nothing", (10) = "change to opposite state", and (11) = "make yang". Thus there is a new level to the 6-7-8-9 encoding, relating digrams to these basic operations.

The idea of 3 choices (yin, yang, pass) may need some motivation. Many times, decisions have an either/or nature, a choice between two alternatives. Courses of action tend to be either dynamic or passive, more yang or yin. But there is also the choice to stand back and let nature take its course without user intervention. While allowing the user to make choices at each step of the reading, we are by no means forcing him to do so. In any given situation, it is up to the user to decide which of these 3 choices corresponds to the real world options being faced, but once an encoding is settled on, the oracle can speak to the matter. Associated with each value of the user choice is one of the 4 basic operations just described. In a hexagram, the first 2 lines give the operation for "pass", the next 2 lines are for a choice of "yin", and the last 2 lines are for a choice of "yang". For instance, the instruction mentioned earlier (010011) can be decoded as follows: if the user passes, do nothing to the line (01); if the user chooses yin, make the line yin (00); if the user chooses yang, make the line yang (11). A high level description of this instruction is "copy the user input, doing nothing if he passes". There are 64 such "instruction hexagrams" or op-codes (not too surprisingly). Some of the more useful instructions include:

A program consists of a sequence of these instruction hexagrams. The instructions in this sequence are numbered 0, 1, 2, etc.; the number for an instruction is called its "address", analogous to "memory addresses" in modern computers. A many worlds line or MWL is simply one of these programs. A many worlds hexagram is a stack of 6 MWLs, all operating in multi-processor mode.

Program Initialization and Termination Conditions

Now that we've covered the syntactic definition of a MWL, there are some semantic questions to consider. By that, I mean we need to define how the program is executed, producing a journey of hexagrams to interpret. Even though the "flow of control" is fairly easy (since this is just straight-line code), there are still several issues that need to be nailed down before MWLs can be considered well defined.

Program Length

One of these programs can be any length desired; the syntactic definition makes no assumptions about the number of instruction hexagrams in any program. This leads to a number of possibilities, giving the oracle operator much latitude as to how complicated a reading he wishes to perform. Generally speaking, these options fall into two main classes, known as "homogeneous hexagrams" and "heterogeneous hexagrams". In the homogeneous case, all 6 lines in the hexagram have the same number of instructions, while in the heterogeneous case, lines can have different lengths.

The homogeneous hexagrams are obviously easier to work with. In fact, satisfactory divinations can be made by simply picking an arbitrary number of instructions for all lines before starting. A default length of 4 is usually more than adequate, although more instructions can be used at the operator's discretion. Alternatively, the yarrow sticks can be consulted in any number of ways to determine program length before constructing the hexagram proper. A major advantage to homogeneous hexagrams is that all lines quit executing at the same time, simplifying the termination conditions.

In heterogeneous hexagrams, the program length for each line must be determined separately. For instance, before creating the instructions for the line, the yarrow sticks can be consulted to determine how many to produce. Several useful schemes for this are explained in the section on "Modifications to the Yarrow Stick Algorithm". If the operator prefers not to leave these decisions up to random processes, he can choose some other scheme instead. Notice however, that heterogeneous hexagrams may have lines that quit executing before the others.

Program Initialization

Because an instruction in a MWL program requires input before it can calculate the next state of the line, we need to make some assumptions about the state of the program before it starts executing. These are known as initialization conditions.

Essentially, in order to calculate the state of a MWL at time t, you need to execute the instruction at "address" t, taking into account certain inputs. One of these inputs is the state of the line at time t-1; the other is the user choice made between time t-1 and time t. This is fine in the middle of the program, but it raises some problems at time t=0, when executing the 0th step of the program. Namely, what was the state of the line before it started executing (how Zen!), and what was the user doing before the oracle was consulted.

As a rule of thumb, it is easiest to assume the user choice was a pass (no decision made) when the program starts. This assumes the situation is simply a "given" and that we don't choose (at an ego level) what lessons Life presents to us. If the querent is in a distinctive frame of mind over the matter at hand, such as excessively yin (fearful or depressed) or yang (excited, overzealous), that can often be used as the initial choice instead. A distinctive mental outlook obviously colors one's outlook on the situation, so it's not unreasonable to assume this coloration should be reflected in differing starting hexagrams.

As for the state of the line before it starts, the most common assumption is to assume all lines are initially yin, i.e., we start with a hexagram of (000000) in order to compute the first hexagram. Of course, any other starting hexagram would work just as well. It's possible for the operator to choose a new hexagram every day, so the workings of the oracle reflect that day's energies better. It is also possible to choose a new hexagram for each client that walks in the door, with each new client picking a "ticket" from 1 to 64 as they enter. Various yarrow stick methods can also be used.

(On a humorous note, I can't help but imagine what the waiting room of an advanced oracle priest must have looked and sounded like. Nobility and wealthy clients are sitting all about in a haze of incense smoke, surrounded by noisy chickens and bags of rice, waiting their turns. The secretary at the front desk is urging all newcomers to "Take a ticket!", while the priest sticks his head in the doorway occasionally to yell above the din, "Now serving hexagram #42!" I certainly hope it was more dignified than that...)

Under these assumptions, it's evident that most of the information in the first instruction is basically ignored. Usually only one line of the 6 is worth mentioning, typically the bottom line of the instruction.

Step-wise Flow of Control

Having decided on the initial conditions for a MWL (an initial yin/yang state and user choice), it's a simple matter to set the program in motion. Execution starts at address 0. At each step of the way (at time = t), the instruction hexagram with address t is used in conjunction with the state of the MWL at t-1 and the user choice after t-1 to calculate the new state of the line. The address is then increased by 1 for the next step. Execution continues until the last instruction in the program is used up, at which point the next group of considerations comes into play.

Program Termination

Program termination is not much of an issue in the homogeneous hexagram case. All lines execute to the completion of their programs and quit simultaneously when they run out of instructions. The hexagram is then done.

Things get a bit trickier with heterogeneous hexagrams, since some lines will complete before other lines. There are a number of viable options for this situation.

The easiest technique is to assume a MWL can no longer change state when its last instruction is completed. It becomes a static line from that point on, so to speak. An equivalent way of implementing this option is to use the NOP instruction as often as needed once the "official" program is completed, since NOPs don't cause any change in the line. This option is thus sometimes called "padding with NOPs".

A more draconian solution is to quit the entire hexagram when any of the 6 MWLs reaches the end of its program. In effect, the shortest program governs the whole hexagram. This has the undesirable effect of making the remaining parts of the other lines superfluous. Considering how many yarrow sticks need to be thrown to create those instructions, this is a huge waste of divinatory effort.

Two other options are reasonable. You could assume that when a MWL reaches the end of its program, it simply repeats the last instruction as often as needed, creating a short but infinite loop at the end of the program. Alternatively, the program could simply start over from the beginning (address 0) if it runs out of instructions, creating a larger infinite loop. In either of these cases, it is important to stop all lines when the largest line reaches its last instruction, if the entire hexagram is to avoid an infinite loop. Conceivably, you could let the hexagram execute indefinitely (though it might get boring after a few hours), letting the operator decide when to pull the plug. At some point, though, enough is enough.

In my opinion, it's best to use the NOP padding mechanism, bounded by the length of the longest program. The looping techniques will be further examined shortly.

Moving Lines

The subject of moving lines needs to be reexamined for MWLs, since the decision of which lines in the hexagram are moving and which are static usually can't be determined ahead of time. Depending on the user choices made during the reading (which determine the particular journey of hexagrams we trace out), a line can be either moving or static. The only way to decide on movement for a line is to do the reading. For instance, a program consisting of UYANG at address 0, followed by (011010) for the next few instructions, describes a line that becomes yang right away, then waits for the user choices to come in. If the user passes at each step, the line stays the same, but if the user chooses yin or yang, the line changes state. Whether the line changes or not is totally up to the user. Other programs are even more complicated. Suffice it to say that for a given sequence of choices, the definitions of movement are similar to the ones for HLs. Namely, the line is locally moving at step t if the line changes state while executing the instruction at address t; it is globally moving if it is locally moving at some step, i.e., if it changes state sometime during the reading.

Relation between HyperEmblematic Lines and MWLs

MWLs wind up being fully backwards compatible with the hyperemblematic lines of my previous article. Any HL can be easily translated into an equivalent MWL, although most MWLs will not have an HL counterpart. The translation is in two steps. First, the HL is converted into its journey n-gram. Second, the journey figure is read off from the top down. When a yin line is encountered, a UYIN instruction is added to the program; a yang line produces a UYANG intstruction. Instructions are added starting at address 0 and then in increasing order. These steps are fully reversible. Note that the journey is read top down, but the corresponding program grows from the bottom up.

Modifications to the Yarrow Stick Algorithm

Quite obviously, the task of creating a many worlds hexagram for a reading is much more complicated than producing a normal hexagram of 6 emblematic lines. A small, but typical many worlds hexagram consists of 6 MWLs, each consisting of 4 (or more) program steps, where each instruction hexagram has 6 basic yin/yang lines, a total of 144 lines. A good yarrow stick operator can generate roughly one line per minute. With a couple of breaks to refill his teacup, it would take nearly 3 hours to cast a hexagram! The venerable yarrow stick algorithm, designed to be slow, becomes intolerable for these more advanced figures. We need to modify the algorithm to allow for the industrial scale production of basic lines. There are quite a large number of options possible for redesigning the technique.

The essence of the yarrow stick technique consists of dividing the total bundle of sticks into piles which are counted down by 4's to produce yin/yang decisions (see Killia [1997]); these results are then translated (or compiled) into emblematic lines via the 6-7-8-9 encoding. Within this 3 step process is much room for tinkering and generalization as we move into more complicated types of figures such as HLs and MWLs.

Unlike the traditional hexagrams, which always have 6 lines in the figure, MWLs are flexible in their "length" or total information content. The first important decision to settle when casting a many worlds hexagram is the length of the programs in the lines. Granted, many practitioners will opt to use a fixed default length (such as 4), but others will prefer some flexibility in this regard. Whether using homogeneous (where one length applies to all lines) or heterogeneous hexagrams (where each line has its own length), yarrow sticks can be used in several ways to choose a length. One simple way is to divide the bundle into 2 piles and count down one of the piles by 4, 8 or some other fixed number. The number of the count will be the absolute maximum length allowed, though the average length will typically be half that number. A more interesting algorithm requires a separate "is the program done?" divination after generating each instruction hexagram. Again, this question is answered by dividing the bundle into 2 piles and counting down one of the piles. If there is one stick remaining at the end of the count, the program is complete; otherwise, you go on to creating the next instruction. While shorter programs are most likely, there is theoretically no upper limit to program size. For instance, by counting down by 4, 90% of the MWLs will have a length of 8 or less, and only 1% will exceed a length of 16. Counting down by a number smaller that 4 decreases average length, while a greater number increases length. Whether used for each line or for the hexagram as a whole, this technique has great appeal.

Having decided on a length for a MWL, the next task is to produce a long string of instruction hexagrams of 6 basic lines each. While the yarrow stick algorithm could be used as is, it's more efficient to create lines wholesale rather that one at a time. For instance, dividing the bundle into 3 piles and counting down by 8 on the first 2 piles produces 2 trigrams (remainders of 1 to 8), a full hexagram in one manipulation. Equivalently, 4 piles which are counted down by 4 generates 3 digrams, also a full hexagram. One practical disadvantage of these approaches is many of the instructions are of a less useful nature, creating programs that cause the lines to move erratically. It would be helpful to bias the instructions to more calm behavior, so that static lines or slowly moving lines are more likely. For example, if 3 trigrams are thrown, which are converted to their equivalent digrams, the instructions would be biased towards (01) and (10) operations, which settles down the programs considerably. While some experimentation with this latter technique would be needed to verify my claims, I feel it would be time well spent. Ultimately, as a consensus on programming style emerges from the oracular community, it should be possible in the long run to create compilers that bias the programs towards the "good" ones.

Actually, the best solution we've found in practice is to use some massively parallel processing facilities common to most research campuses: graduate students. In a typical situation, I arrange the chairs in the classroom into 6 rows of 4 chairs each, which I fill with a grad student, paper and pen, and a bundle of yarrow sticks. A first year student who has mastered Yarrow Stick 101 and basic archeocomputing concepts is sufficient. Each person only has to cast a single hexagram in the traditional manner, but since the 24 students are working in parallel, the many worlds hexagram is ready to go in only 15 minutes. Further, the students can also perform all the program execution work as well, turning the entire room into an efficient oracular computer. I can easily visualize one of the old Wise Ones with a large entourage of initiate, entry-level programmers behind him, coming before the emperor for a reading.

Ultimately, it's probably best to dispense with the yarrow sticks and rely on a computer program. This would have the advantage of being able to programmatically bias the instructions so it resembled some kind of "ideal" mix. It will probably take much research before adequate oracle compilers are available.

Extensions to the Basic Op-codes

Before the design of MWL 1.0 was even completed, it became obvious that it could also be extended in various ways to make the model more versatile. Three directions stand out right away. These are: 1) other kinds of input, 2) more complex flow of control, and 3) the question of "moving code". (An implication of number 2 is that programs can execute multiple instructions at each step instead of just one.) Since all 64 hexagrams are in use, however, it is necessary to expand the instruction size from 6 to perhaps 8 lines, or else redesign this system from the ground up.

In the 1.0 version, there is no interaction between the 6 lines of a hexagram and their movements. They all go through their movements independent of the other lines, just as they did in the old days. However, if a line can use knowledge of its own previous state while executing, there is no particular reason to say it can't use the state of the other lines as well. Or it could look at its history beyond the immediately preceding step. Or it could depend on other inputs we don't even think about. In this paper, the idea of "inputs" was hardwired into the instruction format. Perhaps it is time to separate the notion of inputs into a small set of instructions that can be used by other instructions in a more uniform manner.

The notion of terminating a program by an infinite loop instead of NOPs made us start looking at more complex flow of control issues. Face it, even though the journeys of the hexagram are a tree of alternatives, the programs themselves are still strictly deterministic, straight line code. Some simple looping and decision making instructions (particularly decisions based on input data) would make for some intriguing hexagrams. You could have programs that halt early on some journeys (say, "halt if user chooses yang, otherwise..."), signaling an "end of the discussion" as far as the oracle is concerned. Subroutines would be a good extension, allowing shorter programs to be created. Separate lines in the same hexagram could conceivably interact somehow. All the rich notions of modern computer languages are possible options.

A more obscure direction started popping up during our earliest experiments, namely that the instruction hexagrams of a MWL can contain moving lines. Intuitively, this means that programs can "change" in some manner. Frankly, we've never figured out how these movements relate to the original idea of the MWL state moving over time. There seems to be be two distinct concepts of "time" or stepwise change going on here. It gets worse if the moving hexagrams have HLs or even MWLs for lines instead of simple emblematic lines. While some may quibble whether this is "true" self-modifying code or not, it's close enough to start creating some Gödelian conundrums that are very disquieting. Self-modifying code is generally frowned upon in programming circles because of the many problems it causes. Until these issues are examined more carefully, I'd recommend taking a "Wise One cop out" approach. Gaze admiringly at the program instruction with the moving lines, smile a faint, inner smile that communicates you are forever amazed at the subtle ways of the Tao, then work with the hexagram as though the lines were static.

Rather than expand the instruction set, I suspect it's probably more useful in the long run to scrap the current approach and try to simplify the model as much as possible, perhaps along the lines of Alan Turing's landmark 1936 paper. Getting back to basics is likely to get us closer to the machines found in the Oracular Temple than more complex models will. The dream of the temple priests was a general purpose oracular computer that would carry out the mundane calculations of the Q-Ching, leaving the subtle interpretive work for the operator. Many designs were discussed, but one of the more successful designs (apparently) was for something called a "Tui-Ling Machine". Modern scholars would love to resurrect this ancient machine, since it would tell us so much about the deeper nature of the Q-Ching. We can only hope that our modern research will take us closer to this "holy grail" of archeocomputing.