Date: 15 Jan 1986 16:02:25 EST (Wed) From: Dan Hoey To: SF-LOVERS Subject: NIGHT OF POWER by Spider Robinson Spider Robinson's new novel is out in paperback. NIGHT OF POWER is a near-future look at the prognosis for racial conflict in the United States. It's got startlingly realistic cultural and technological extrapolation, full of the usual Spider loving kindness and tender philosophy, leavened with an unusual amount of sex and violence. People whose stomachs will not take the S&V are to be pitied, for they will miss a good read. People who *like* S&V will be teased, but not spoiled, by the information that he describes an achingly beautiful first orgasm, and the most imaginative homicide I have ever heard of. For those of you who want to see slant labels on their sex, let me warn you that the sex is all hetero, and touches on (and occasionally fondles) prostitution, rape, pubescents, adultery, and (gasp) miscegenation. This notice is a transparent excuse for offering my opinion that people who want sexual orientation labels on book covers have their head in the sand or worse. I'd rather that novelists feel free to include whatever form of sexuality will serve their theme, but that warning labels be required on the dull, trite, boring, unreadable, stupid slush that fills ninety percent of the bookshelves. Which is harder to identify with, characters full of lust for members of their own sex, or characters full of nothing at all? I am glad to see that Spider, famed nemesis of the Hax of Sol III, has taken the initiative in instituting my scheme of warnings. The absence of inanity labels on NIGHT OF POWER is true truth in advertising. Dan --- Date: 31 Jan 1986 17:45:15 EST (Fri) From: Dan Hoey To: RISKS Subject: VDT's and birth defects in mice Yesterday I heard a radio report that a Swedish study found that video display terminals increased the incidence of birth defects in mice. Does anyone have more information on this? I have not previously heard of any controlled research in the area that has identified a hazard. I am interested in trying to find out what the results of the study indicated, whether it is a new result, and how credible it is. Dan --- Date: 27 Feb 1986 16:44:50 EST (Thu) From: Dan Hoey Subject: Re: Keyboards To: "Keith F. Lynch" Cc: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA Date: Sat, 22 Feb 86 15:24:38 EST From: "Keith F. Lynch" Subject: Keyboards To: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA Cc: KFL@MC.LCS.MIT.EDU, Info-VAX@SRI-KL.ARPA I think INFO-VAX has had enough. INFO-TERMS may be interested, but probably not. From: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA ... Somehow I doubt that DEC gives you the option of changing what the keyboard sends. ^space isn't a null?? Control-space should not be a null. Control-@ should be a null. Pressing a character key while holding down control should subtract 64 from that character code, or should leave it alone. On the H19 control-space is a space, since 32-64 is not in the ASCII set. The IBM-PC keyboard (despite its strange key placements) does this right, as it allows user software complete control. ...Keith Well, I like complete control, too. C-@ is the standard NUL, but why not C-space too? For that matter, I have C-2 make a NUL, so I don't have to shift. Similarly, for US (31), I use C-_ because it's ``right'', C-- because I forgot to shift, and C-/ and C-? because they are convenient. But ``subtracting 64'' is much too simplistic. When you type C-a (as opposed to C-A) would you expect to get a !? I thought a better algorithm was to mask with 31. Then C-space is really NUL, as is C-`. Dan --- Date: 12 Mar 1986 17:51:45 EST (Wed) From: Dan Hoey Subject: Re: XON XOFF and EMACS To: "Keith F. Lynch" , DEVON@MIT-MC.ARPA, rms@MIT-PREP.ARPA, mcvax!delphi!mdc@SEISMO.ARPA In-Reply-To: All this XONXOFF garbage on INFO-VAX 1. Sending ^P^S/^P^Q doesn't work very cleanly, because your terminal may want to do flow control between ^P and the following character. You need some sort of sequence that avoids ^S and ^Q entirely. 2. The solution to the Emacs problem is to get a keyboard you can program so that when you hold down Control and press S or Q or P, you get the appropriate sequence sent to your machine. 3. Please don't send this to INFO-VAX. You may want to send it to INFO-TERMS, but it is really not at all a VAX problem. Dan --- Date: 13 Mar 1986 12:49:33 EST (Thu) From: Dan Hoey Subject: Re: XON XOFF and EMACS To: mcvax!delphi!mdc@seismo.ARPA Cc: KFL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA, rms@MIT-PREP.ARPA From: mcvax!delphi!mdc@seismo.CSS.GOV Date: Thu, 13 Mar 86 13:47:42 MET To: Dan Hoey 1. Sending ^P^S/^P^Q doesn't work very cleanly, because your terminal may want to do flow control between ^P and the following character. I agree. May be the flow control strategies of the terminal/device driver can avoid the problem, if they do some form of look ahead. I think it is a bad idea to infer data based on timing. This locks you out of interesting communications possiblities like networks, error-correcting modems, etc. Each step of the communications chain may be passing XONs and XOFFs back and forth, and some of them are sure to come right after the ^P. You need some sort of sequence that avoids ^S and ^Q entirely. So ^Q and ^S can be substituted only with other ASCII chars. And the problem is there again . Not so! For instance, have (keyboard) Control-S send (ascii) ESC ' S, C-Q send ESC ' Q, and the Esc key send ESC ' [ if you like. There's plenty of space in ASCII code, you just need to usurp another character. The reason I have chosen ESC here is that it has already been usurped by ANSI escape sequences. (I think these sequences ' are unused and follow the form of the standard, but there are many more available if I am wrong.) The terminal driver can then use ^S and ^Q for flow control, convert the above escape sequences into ^S/^Q/ESC, and pass all other escape sequences transparently to the application. Another possibility is to have the other escape sequences converted into some sort of magic cookie to signify the function key that was pressed. The driver should also be able to optionally pass a magic cookie to indicate the XON/XOFF flow control. This is so that the application program can know that it's output is stopped, and possibly avoid queueing more stuff up. This is important when the application is TELNET or some other virtual terminal program. There are a bunch more interesting cookies that could be sent from the driver, like ``user is flushing output, don't bother to format it'' or ``user wants to talk to TELNET, rather than through it''. There has been work in designing transparent protocols for this stuff, but most terminal drivers and most keyboards aren't smart enough. Dan --- Newsgroups: net.unix-wizards From: hoey@nrl-aic.arpa (Dan Hoey) Date: Wed, 16-Apr-86 19:53:26 EST Subject: Newer revised HTABLE for 4.2BSD Here are context diffs for /usr/src/etc/{scan.l,htable.h} that will allow machines like 3B2 and hosts like UCBVAX.Berkeley.EDU. It shouldn't have any problem with one-character host names, either. This diff is between the 4.2 scan.l and the new one. If you have applied the change Mike Muuss sent out yesterday, the form of your {ALPHA} rule will be different but the effect is the same: the rule is deleted, because it is handled by the revised rule. This change will NOT handle machine types like "360/50". Tokens must contain an alphabetic character before the first slash, dot, or hyphen. This prevents ambiguity in parsing octet notation. And yes, this will accept some invalid syntax, too. The Hostmaster will have to get a new canary. Dan Hoey *** 4.2/scan.l Thu Jun 30 20:19:45 1983 --- scan.l Wed Apr 16 12:10:14 1986 *************** *** 9,17 BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Z] ! ANUM [0-9A-Z] ! NAMECHR [0-9A-Z./-] %% "NET" { --- 9,17 ----- BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Za-z] ! ANUM [0-9A-Za-z] ! NAMECHR [0-9A-Za-z./-] %% "NET" { *************** *** 29,36 return (KEYWORD); } ! {ALPHA}{NAMECHR}*{ANUM} { ! yylval.namelist = newname(yytext); return (NAME); } --- 29,36 ----- return (KEYWORD); } ! {DIGIT}*{ALPHA}{NAMECHR}* { ! yylval.namelist = newname(lower(yytext)); return (NAME); } *************** *** 33,40 yylval.namelist = newname(yytext); return (NAME); } - - {ALPHA} return (NAME); {DIGIT}+ { yylval.number = atoi(yytext); --- 33,38 ----- yylval.namelist = newname(lower(yytext)); return (NAME); } {DIGIT}+ { yylval.number = atoi(yytext); *** 4.2/htable.h Thu Nov 3 15:35:32 1983 --- htable.h Wed Apr 16 10:47:32 1986 *************** *** 34,39 #define KW_HOST 3 struct name *newname(); char *malloc(); char *infile; /* Input file name */ --- 34,40 ----- #define KW_HOST 3 struct name *newname(); + char *lower(); char *malloc(); char *infile; /* Input file name */ ================ End of diffs. --- Newsgroups: net.sources From: hoey@NRL-AIC.ARPA (Dan Hoey) Date: Wed, 23-Apr-86 22:46:16 EDT Subject: A or An Gregory Smith noticed that festoon didn't choose the indefinite article correctly. His simplistic solution prompted0me to convert a baroque Lisp hack I wrote into C. This one knows about the difference between an hour and a houri, between an herb and a herbivore, etc. It can't tell the difference between a unionized factory and an unionized gas, though. You may think some of my choices are capricious. Edit to taste. Dan Hoey Hoey@NRL-AIC.ARPA # Cut and compile # /* * Routine to decide between "a" and "an". * * Usage: char *a_or_an(s), *cap_a_or_an(s) * char *s; * * a_or_an(s) returns "a" or "an", whichever is the appropriate indefinite * article for the phrase s. cap_a_or_an returns "A" or "An". * * Define DRIVER to make a filter that prepends 'a' or 'an' to each line. * * Author: Dan Hoey 23 April 1986 */ #include /* Pat is a sorted table of lower-case prefixes. * If Pat contains an even number of prefixes of a given word, * the word takes "an"; otherwise the word takes "a". */ static char *Pat[] = { /* Everything is a consonant (except an apple, */ /* an exception (except a euphemism (except an Eulerian)), */ "a", "e", "eu", "eule", /* an F (except a foo), */ "f", "fa", "fe", "fi", "fj", "fl", "fnord", "fo", "fr", "fu", "fw", "fy", /* an H (except a ha (except an habanera), */ "h", "ha", "haban", /* a he (except an heiress, an Henry, or an herbalist */ /* (except a herbaceous, a herbarium, a herbert, or a herbivore)), */ "he", "heir", "henry", "herb", "herbac", "herbar", "herbe", "herbi", /* a hi (except an Higgins), */ "hi", "higgin", /* a ho (except an homage, an hombre, an honest, an honorarium, */ /* an hors d'oeuvre (except a horse, a horst, or a horsy), */ /* an houdaille, or an hour (except a houri)), */ /* a Hrothgar, a hug, or a hype), */ "ho", "homa", "hombr", "honest", "honor", "hors", "horse", "horst", "horsy", "houdai", "hour", "houri", "hr", "hu", "hy", /* an iota, an L (except a lot), an M (except a multitude), */ "i", "l", "la", "le", "lf", "lh", "li", "ll", "lo", "lu", "ly", "m", "ma", "mc", "me", "mi", "ml", "mn", "mo", "mr", "ms", "mu", "mw", "my", /* an N (except a number), */ "n", "na", "nb", "ne", "ng", "ni", "no", "nu", "ny", /* an other (except a once and future or a one (except an Onega, */ /* an oneiromancer, or an onerous), */ "o", "once", "one", "oneg", "onei", "onero", /* an R (except a riot), an S (except a superfluity), */ "r", "ra", "re", "rh", "ri", "rm", "ro", "ru", "rw", "ry", "s", "sa", "sc", "se", "sf", "sh", "si", "sj", "sk", "sl", "sm", "sn", "so", "sp", "sq", "sr", "st", "su", "sv", "sw", "sy", "sz", /* an udder, an ugh (except a Ugandan), an uh, */ /* an ulcer (except a Ulysses), an um, */ "ud", "ug", "ugan", "uh", "ul", "ulys", "um", /* an unlikelihood, (except a unanimity, a unanimous decision, */ /* a unary count, */ "un", "unanimi", "unanimo", "unary", /* a universal botch (except an unidentified case (except */ /* a unidimensional one), an unignorable, an unilluminated, */ /* an unimpressive (except a unimodal), */ "uni", "unid", "unidi", "unign", "unill", "unim", "unimo", /* an uninteresting (except a uninominal), an uniodized, */ /* an unironed (except a uniroyal), */ /* an unissued, an unitalicized, an unitemized uneogh!!)), */ "unin", "uninom", "uniod", "unir", "uniroy", "uniss", "unital", "unitem", /* an upper at last, an urge, (except a uranous, a ureous, */ /* a uriniferous, a urologist), an usher, an utmost or an utter one, */ /* an uxoricide with an Uzi, an X (xcept a xoo), */ "up", "ur", "ura", "ure", "uri", "uro", "ush", "utm", "utt", "ux", "uz", "x", "xa", "xe", "xi", "xu", "xy", /* an yclept, an Yggdrasil, an ylang-ylang, an yngvi, an yttride, */ /* or an yvette) */ "yc", "yg", "yl", "yng", "yt", "yv"}; /* Find number of prefixes of s in Pat. Return 1 if odd, 0 if even. For each initial alphabetic substring of s, binary search with the active region being Pat[bot] through Pat[top]. Also maintains an active region for each possible continuation of the substring, being Pat[pbot] through Pat[ptop]. */ static an_phrase_p(s) char *s; { int slen; /* length of prefix of s */ int pbot = 0; /* bounds on Pat */ int ptop = sizeof (Pat) / sizeof (char *) - 1; int nfound = 0; /* number of prefixes of s found */ register int sc, /* input char - pat char */ si, /* char index */ mid, /* binary search parameters */ bot, top; for (slen = 0; isascii (s[s6en]) && isalpha (s[slen]); ++slen) { /* For each alphabetic prefix s[0..slen] */ bot = pbot; top = ptop; while (bot <= top) { /* binary search for the prefix */ mid = (bot + top) / 2; for (si = 0; si <= slen; ++si) { /* for each char in the prefix */ if (isupper (sc = s[si])) sc = tolower (sc); sc -= Pat[mid][si]; if (sc > 0) { /* mismatch: string>pat */ pbot = bot = mid + 1; break; } if (sc < 0) { /* mismatch: string slen) { /* prefix sequence matched */ if (Pat[mid][si]) {/* but pattern continues */ top = mid - 1; } else { /* exact match */ ++nfound; pbot = mid + 1; break; } } } if (pbot > ptop) break; } return (nfound & 1); }; char *a_or_an (s) char *s; { return (an_phrase_p (s) ? "an" : "a"); } char *cap_a_or_an (s) char *s; { return (an_phrase_p (s) ? "An" : "A"); } #ifdef DRIVER #include #define MAXLINE 256 main (argc, argv) char *argv[]; { char s[MAXLINE]; if (argc > 1 && !freopen (argv[1], "r", stdin)) { perror (argv[1]); exit (1); } while (fgets (s, MAXLINE, stdin)) { if (isascii (*s) && isupper (*s)) printf ("%s %c%s", cap_a_or_an (s), tolower (*s), s + 1); else printf ("%s %s", a_or_an (s), s); } }; #endif DRIVER --- Date: 25 Apr 1986 13:00:38 EST (Fri) From: Dan Hoey Subject: SU Shy Flambe To: Info-Cobol@MIT-MC.ARPA >Date: Thu 24 Apr 86 09:30:26-PST >From: Evan Cohn >Subject: Flaming Statistics >To: su-bboards@su-sushi.arpa > >Yesterday the redoubtable H. K. A. Hussein reeled off 10 messages, >containing 21,289 characters, to the sushi bboard. At this blistering >pace he would produce 7,770,485 characters per year. If each >character were 1 cm long he would then have a character string 48 miles >long, just shy of the distance from here to the moon. If each >character were a mile long, however ... his messages would have a lot >more impact. If each character were a bean he would have a truly >enormous pile of beans. Those are the statistics. >------- >From: Kennita L. Watson >Subject: Hussein's flames > >Evan: if 48 miles is just shy of the moon, we had all better get out >our hard hats. > >------- >From: Vaughan Pratt >Subject: shy of the moon? > > Evan: if 48 miles is just shy of the moon, we had all better get out > our hard hats. > >or recalibrate yourself on how shy you have to be before Evan notices. >-v --- Newsgroups: mod.protocols Date: 11 Aug 1986 12:08:06 EDT (Mon) From: Dan Hoey Subject: CRC-16 To: Kaufman@SU-SHASTA.ARPA, jr@bbncc5.ARPA Cc: ProtocolS@Rutgers.ARPA A couple of errors appeared in recent postings about CRC-16 error checking. From: Marc Kaufman CRC-16 is extremely susceptible to even-number-of-bit errors. For example, the following error pattern will not change the CRC: 10000100000010001 (binary), where '1' indicates a bit error.... The example applies to the CCITT V41 polynomial. The CRC-16 polynomial is different, so the example should be 10100000000000011 (binary), where '1' indicates a bit error. or, if you are a big-endian, 11000000000000101 (binary), where '1' indicates a bit error. Subject: Re: Interview with MNP protocol author Date: 05 Aug 86 17:09:30 EDT (Tue) From: John Robinson ...>>> Using the 16-bit redundancy check, it will detect every >> error which is 16 bits or smaller, with 100% probability. No! No! No! Any error in an odd number of bits, and all one-, two-, and three- bit errors will be detected. 16 bits in a row which are inverted are detected, yes (I think!), but a sequence of 16 bits in which some bits are in error is NOT necessarily detected. CRCs aren't that good.... The original statement is correct. Both CRC-16 and CCITT V41 will detect any error that is a subset of sixteen consecutive bits. (Not to say that's all that good, as we have seen.) This can be seen by noticing that nonzero multiples of a degree sixteen polynomial must have degree at least sixteen. The only undetected pattern that spans seventeen bits is the polynomial itself, as shown above. Dan Hoey --- To: Physics@SRI-Unix Subject: Physics of Tidal Forces Date: 4 Sep 1986 16:02:11 EDT (Thu) From: Dan Hoey From: ernie.Berkeley.EDU!rimey@UCB-Vax.arpa (Ken Rimey) >I calculate that the tidal effect [on] an orbiting body is half >again as big as the tidal effect [on] a radially inward falling body. To follow up on my own message, I guess the reason this effect is slightly obscure is that it doesn't affect the Earth's lunar tide, only its smaller solar tide. I fail to see why the effect would occur on one and not the other, since both the moon and the sun orbit the earth. Or do you think we are falling into one or the other? Dan P.S. -- If you have a trigger-happy reply key, please repeat the mantra ``and vice versa'' a few times. D. --- Date: Mon, 15 Sep 86 08:51:16 edt From: Dan Hoey To: SF-LOVERS Subject: Re: Jittlov news? Cc: hoptoad!farren@ru-caip.ARPA I was puzzled in Atlanta by the announcement of a program item called "The Forgery of Mike Jittlov's Autograph" scheduled for presentation by Lisa Winters. I couldn't make it, and I later heard the item was cancelled. Do you have any idea what it might have been about? Is there a new fanscandal brewing? --- Newsgroups: mod.ai Date: 25 Sep 1986 14:45:40 EDT (Thu) From: Dan Hoey Subject: Xerox vs Symbolics -- Reference counts vs Garbage collection In AIList Digest V4 #191, Steven J. Clark responds to the statement that ``Garbage collection is much more sophisticated on Symbolics'' with his belief that ``To my knowledge this is absolutely false. S. talks about their garbage collection more, but X's is better.'' Let me first deplore the abuse of language by which it is claimed that Xerox has a garbage collector at all. In the language of computer science, Xerox reclaims storage using a ``reference counter'' technique, rather than a ``garbage collector.'' This terminology appears in Knuth's 1973 *Art of Computer Programming* and originated in papers published in 1960. I remain undecided as to whether Xerox's misuse of the term stems from an attempt at conciseness, ignorance of standard terminology, or a conscious act of deceit. The question remains of whether Interlisp-D or Zetalisp has the more effective storage reclamation technique. I suspect the answer depends on the programmer. If we are to believe Xerox, the reference counter technique is fundamentally faster, and reclaims acceptable amounts of storage. However, it is apparent that reference counters will never reclaim circular list structure. As a frequent user of circular list structure (doubly-linked lists, anyone?), I find the lack tantamount to a failure to reclaim storage. Apparently Xerox's programmers perform their own careful deallocation of circular structures (opening the cycles before dropping the references to the structures). If I wanted to do that, I would write my programs in C. I have never understood why Xerox continues to neglect to write a garbage collector. It is not necessary to stop using reference counts, but simply to have a garbage collector available for those putatively rare occasions when they run out of memory. Dan Hoey --- Newsgroups: net.unix-wizards From: hoey@NRL-AIC.arpa (Dan Hoey) Date: Fri, 17-Oct-86 13:47:26 EDT Subject: Do not use blank lines in /etc/passwd Date: Mon, 25 Aug 86 11:15:24 edt From: sscalsk@nswc-wo.arpa Anybody ever had a blank line as the first line in your password file? It happened to me a few weeks ago and the system would not let any user at all log on. Su did not work either.... At least in vanilla 4.2, having blank lines anywhere in your password file opens a security hole that I will forbear to discuss on this list. I have not verified this on other systems, but I advise you to stick to the standard format. If you want to insert blank lines for readability (which is how I discovered the bug) use nearly-blank lines like x:*:0:0: :: assuming that "x" is not a user on your system. Dan Hoey hoey@NRL-AIC.ARPA --- Date: Thu, 06 Nov 86 13:41:48 -0500 (EST) From: Dan Hoey To: Cube Lovers Subject: Magic I have three macros for transforming 2x4 rectangles. To solve the puzzle, I use two of them followed by a seven-flip macro that changes a 2x4 shape into a 3x3-1 shape (beats me how BECK can call this a ``2x3x3''). Took me a couple of half-days to solve it. I have found 32 different 2x4 rectangles. I think that is all of them, but I haven't got any proofs, nor even a decent mathematical model for deciding when a flip is possible. I am trying to understand how the strings work. First, it looks like there is twice as much string as necessary; each string is doubled. I guess that this duplication has no effect on the puzzle except for durability, but until I can dyke one out can't be sure. I'm concerned that the string may be one double loop, so I'm looking for a good way to make sure the thing doesn't unstring entirely when I cut one. Each side of each piece has four short channel segments and four long; half are occupied with string. If you continue each segment across each hinge to the next piece, you get eight channels composed of alternating long and short segments. Again, four of the eight channels are occupied. In the positions I've seen, each of the channels contains eight pairs of segments. But Magic is more complicated than that--the strings do not always follow a channel from piece to piece. On half of the pieces, there is an extra loop of string that wraps back onto the piece without following the channel to the next piece. I don't know what function this serves. If a good model of the string interactions can be developed, we may be able to make an attack on the doughnut problem based on the length of string channels. In the doughnut, there are four ten-pair channels and four six-pair channels. We may be able to show that the string wouldn't reach one, and would exceed the other. More likely, the model will prohibit the doughnut more directly. There is another string-related question I am wondering about. I have noticed some of the string-pairs getting twisted. I wonder how bad this can get. Does anyone have an operation that can be repeated to make the twists tighter and tighter? Are these puzzles built for obsolescence? I have been considering Magic metrics, but it's a difficult problem. Counting flips is easy enough, but how do you count a move that skews a parallelogram? Are such skew moves necessary? Dan --- Date: Thu, 13 Nov 86 13:16:44 -0500 (EST) From: Dan Hoey To: Cube Lovers Subject: Magic Date: Thu, 6 Nov 86 18:13 EST From: Allan C. Wechsler ... Here is my model. It might be wrong. From what I have seen of the puzzle, your model seems to correctly specify necessary conditions for puzzle movement. I have some additional constraints, below. Each pair of squares is bound together by two loops of string (nylon fishing wire, actually). This is acceptable for a model, though the physical puzzles I have seen are have twice as much wire on half of the squares as on the others. I don't know why, and I am nearly ready to take one apart just to verify my several curiosities about the construction. ... Only the square on the right (the rotor) will move. Keep the left square (the stator) fixed. Flip the rotor .... You have moved the rotor all the way around the stator. At some point, each edge of both served as the hinge. This amazing orbit is the basis for the bewilderingness of the puzzle. The path is a bizarre three-dimensional cloverleaf. This corresponds with my understanding of two-square interaction. Thanks for nailing it down. I think that I have now given all the "laws of motion" of the puzzle. There is something more, because each square has *two* neighbors. Consider a stator with two rotors. There are two ``bizarre three- dimensional cloverleaves'' about the stator, but both rotors move in the same b3dc. Furthermore, they cannot pass each other in their common b3dc. Thus if one goes around more than a complete revolution, the other must make a net advance in the same direction. Since the laws are all local, governing the motion of one adjacent pair of squares, there is no obvious invariant that forbids the doughnut. I think I can demonstrate one, given the fact that the pieces are joined in a cycle. Let us tie each pair of adjacent squares together as in your model. We notice that in the starting position, each of the occupied channels is occupied by two wires, one for each neighbor of the square. Suppose we dyke out a loop from the left neighbor, and splice the left neighbor's connections into the right neighbor's loop. Then do this all the other duplicate loops. I believe we end up with a puzzle held together by four pieces of wire, each (* 8 (sqrt 2)) units long. One of them is drawn below, assuming transparent squares. I believe that this puzzle will move in the same way as the original one. ---- ---- ---- ---- |/\ | |/\ | | |\ \ | /| \ | | | \ \| / | \| | | \ |\/ | |\ | ---- ---- ---- ---- | \| | /\| \ | | |\ | / |\ \ | | | \ |/ | \ \| | | \/| | \/| ---- ---- ---- ---- Now put away the dykes and try to fold the puzzle into a doughnut. If you succeed, you will have formed two (* 10 (sqrt 2)) wires and two (* 6 (sqrt 2)) wires: ---- ---- ---- ---- ---- ---- |/\ | |/\ | | |/\ | | |\ \ | /| \ | | /| \ | | | \ \| / | \| | / | \| | | \ |\/ | /| | / | |\ | ---- ---- ---- ---- ---- ---- | \| | / | |/ | | \ | | /| | / | |\ | | \ | | / | |/ | | \ | | \| | / | |\ | | \ | | /| ---- ---- ---- ---- ---- ---- |/ | /\| \ | | \| | / | |\ | / |\ \ | | |\ | / | | \ |/ | \ \| | | \ |/ | | \/| | \/| | | \/| | ---- ---- ---- ---- ---- ---- Changing the string lengths is a little more magic than I expect from Rubik. My thanks to John Robinson for encouraging me to believe that the string-length criterion has merit. He tells me Andy Latto has a similar proof. Dan --- Date: 17 Nov 1986 16:10:14 EST (Mon) From: Dan Hoey Subject: Speed of light To: Physics@SRI-Unix.ARPA, KFL@MIT-AI.ARPA Cc: hemphill@nrl-aic.ARPA Date: Thu, 6 Nov 86 23:57:34 EST From: "Keith F. Lynch" ... Since 1982 the length of the meter (and hence of the inch, mile, etc) has been defined in terms of the length of the second and the speed of light. This means that the speed of light is now constant by definition. This also means that since 1982, nobody has measured the speed of light. Anyone who thought he was doing so was actually measuring the length of the meter! ...Keith As I recall, the definition is chosen so as to make the speed of light an integral number of meters per second. Do you know the number? Also, I have heard that the integral number of m/s applies only at some experimentally convenient ultralow pressure, and that the speed in vacuum is still subject to errors in measurement of refractive index. Can you corroborate or debunk this? I mostly want the value to make an accurate not-just-a-good-idea-it's- the-law (or my-limits) bumper sticker or button for a change. The common approximation of 186000 mi/s is galling, since so many people take it for scripture. Speaking of scripture, my grandfather was into biblical numerology (for lack of a better term). He took a phrase about the light of heaven being a thousand times that of the earth, and wrote a paper about the length of heaven's light year and the number of square LY in heaven and the like. Of course he used 186000 mi/s and carried his results out to dozens of figures. What stupefied me was his use of a year composed of 24*365 + 12/4 hours. This from a man who was alive in 1900! And what cretin decided to metrify our speed limits into km/hr, anyway? Dan Hoey ---