Programming the BRGC is almost embarrassingly simple. This stroke of good luck occurs because many programming languages typically have two necessary procedures virtually built right into them.

One is a sort of fixed-point division. In BASIC, this operation has even been given its own symbol, the "\". Thus, "a = b \ c" would mean to divide b by c, to make a the quotient and then to throw away the remainder.

The other operator is designated by "XOR" in BASIC and by "^" in C and in C++. Its name comes from logic, and from the phrase "exclusive or." In English prose, one can think of taking one thing or another, but not both. From this logical beginning, the "XOR" idea eventually evolved into an operator that can be used between two whole numbers. It considers comparable bits, applying the "one or the other but not both" idea to produce a result. It is equivalent to addition, modulo two.

To find the BRGC Disguise (equivalent) for any given integer, one must first halve the number, throwing away the remainder. Make sure that the original number is also retained. The final step is simply to perform the XOR operation between the original number and the halved-and-trimmed number. The result is the BRGC equivalent.

Using the BRGC

In looking for ways to disguise numbers usefully, one hopes to find a few interesting combinations of regularity and irregularity. With the BRGC, such combinations abound. For one thing, the BRGC equivalent of a number is usually only a little bit smaller or a little bit larger than the number itself. It can never be less than half of the parent number, nor more than double it. Except in the cases of 0 and 1, it can never be the number, itself.

If the BRGC algorithm is applied again and again, the original number eventually returns. The question of how soon it will return leads to perhaps the single most fascinating and useful of all the BRGC's many fascinating and useful qualities.

Since "10" is the brgc bit-pattern for three and "11" is the brgc bit-pattern for two, we would say, using brgc notation, that brgc(2) = 3 and also that brgc(3) = 2. Similarly, it turns out that brgc(0) = 0 and brgc(1) = 1.

Moving higher through the numbers, we discover that brgc(4) = 6, that brgc(5) = 7, that brgc(6) = 5, and that brgc(7) = 4. We also see that 0 and 1 exist in cycles of length one; that 2 and 3 belong to a cycle of length two; and that 4, 5, 6, and 7 belong to a cycle of length four.

It happens that all the numbers between 4 and 15 are members of cycles of size four, while all the numbers between 16 and 255 are members of cycles of size 8.

That is as high as I've investigated exhaustively. But my intuition, along with a few random testings, suggest that for all numbers between 256 and 65535 the cycles are of size 16.

Before listing cycles for numbers larger than 7, let us define a few terms. The length of a cycle is one more than the number of transformations necessary before encountering a number already in the given cycle. The head of a cycle is the smallest number in it. The tail of a cycle is the final number in the cycle begun with the head. Note that the tail is not necessarily the largest number in a cycle, though sometimes it will be. Note also that by necessity brgc(tail) = head, for any cycle.

Let us examine the cycles described already. The length of the first cycle is one. Its head and tail are both zero. In the second cycle, the length is again one, whereas this time the head and tail are both one. In the third cycle, the length is two, the head is two, and the tail is three. In the fourth cycle, the length is four, the head is four, and the tail is seven. But the tail is seven not because it is the largest number in the cycle, but rather because it is the last number.

On the next pages are listed the cycles for all integers between 0 and 255, inclusive. Each list begins with the cycle's head, and ends with its tail.

Many patterns can be discerned by studying these cycles. My favorite conjecture is that these brgc cycles are closely related to Nim Multiplication, and that they can be used in programming Nim Multiplication in a new and more efficient way.

I leave it up to the readers to confirm or reject my conjecture, and to dream up conjectures of their own. I encourage everyone to communicate all and any thoughts and discoveries to me.  swhealton@ctsmd.com

Taken together, the diverse features of the BRGC Transformation make it a useful tool. Equally important, when a simple BRGC disguise is used with one or more numbers being fed into a simple formula, the musical or visual result is quite often an interesting one.