From: Tim May <tcmay@got.net>
Date: Tue, 28 Oct 1997 01:44:15 +0800
To: cypherpunks@Algebra.COM
Subject: Re: Orthogonal (fwd)
In-Reply-To: <199710270528.XAA02347@einstein.ssz.com>
Message-ID: <v03102802b07a6f008196@[207.167.93.63]>
MIME-Version: 1.0
Content-Type: text/plain




At 9:47 AM -0700 10/27/97, Kent Crispin wrote:

>At this point, it is clear that I should simply refer you to an
>elementary linear algebra text.  I will just repeat that, for those
>that are familiar with linear algebra, the analogical use of "orthogonal"
>in language design is pretty intuitive.  If you don't have the
>background you may not have the intuition, and discussion on this list
>probably isn't the best way to build it.

I returned home after being away to find half a dozen or more posts arguing
about the use of the word "orthogonal." Which I used in my essay Saturday.

Like Kent, I don't see any point in arguing basic concepts of linear
algebra, vector spaces, correlations, inner products, and how these ideas
relate to machine and language functions. This is stuff most of us learned
way, way back, and the usage for machines and languages is natural. Arguing
about what a "basis" is, or what a "linear combination" is, is just a waste
of time.

I will give just _one_ example of orthogonality, though. Imagine a 747,
with various commands or functions to do things like lower the wing flaps,
retract the landing gear, dump excess fuel, turn on cabin lights, signal an
emergency, etc.

Normally, most of these commands are "orthogonal" to each other, in that
issuing a command to turn on the cabin lights does not also lower the
landing gear. Orthogonal in that there is no "projection" of one vector
onto the other. (Viewed in another way, the inner product of the two
commands is zero, or nearly zero, meaning there is no correlation, or
interaction, between the commands or vectors.)

(If Jim Choates quibbles in a overly literalitst way that "commands are not
vectors," I don't plan to respond.)

Contrast this orthogonal situation to one where one had these kinds of
commands:

Command 353: Lower landing gear, turn on cabin lights, and release
emergency braking parachute.

Command 792: Raise landing gear, send out emergency signal, and
depressurize cabin.

(The above examples might be a kind of "complex instruction set" for a
plane, because some architect decided that Command 353 _might_ conceivably
be needed someday. A cleaner, more functionally orthogonal instruction set
would be more like a RISC architecture.)

These commands would "intereact" with each other. The inner product, or
measure of correlation, would be far from being zero.

In fact, this 747 example is not original to me. When people discuss
software complexity, where small changes can have huge effects elsewhere,
one may hear examples like: "When a pilot tells the plane to raise it wing
flaps, he doesn't expect the tail section to fall off." Meaning, clean
design limits global propagation in various ways, keeps functions fairly
simple, and minimizes interactions and side effects.

Thus is the connection between my usage and software.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."