*****    ***         *     *   ****   *****  *****   ***
         *       *   *        **    *  *    *    *    *      *   *
         *          *         * *   *  *    *    *    *      *
         ****      *    ****  *  *  *  *    *    *    ***     ***
             *    *           *   * *  *    *    *    *          *
             *   *            *    **  *    *    *    *      *   *
         ****    *****        *     *   ****     *    ******  ***

         Volume 3 Number 8       48/39/38              August 1978

                     Newsletter of the SR-52 Users Club
                                published at
                           9459 Taylorsville Road
                              Dayton, OH 45424
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Suppressed Operand Instructions (57)
     Steve Halko (917) has been exploring ways to generate pseudos on
his 57, and while he hasn't yet found a way to generate new instructions,
he has discovered some interesting (and in at least one case, useful)
properties of merged instructions whose operands have been suppressed.
Such an instruction (SOI) is generated in LRN mode by keying SST in-
stead of the operand.  For example, in LRN mode, the sequence GTO 2
normally produces the merged code 51 2.  The sequence GTO SST 2 pro-
duces 51 at one step and 02 at the next.  Steve suggests writing this
as GTO:: 2.  Upon encountering this sequence in a running program, the
machine makes an unconditional branch to the first numeral 2 appearing
in the program.  For example, write 00:  L1 123 L2 45678 R/S L3 GTO:: 2
L4 GTO 2.  In RUN mode SBR 2 or SBR 4 result in 45678 displayed, as
expected, but SBR 3 produces 345678, indicating that the GTO:: 2 caused
a branch to the 03 at step 03 "labeled" by the 02 at step 02.  As Steve
points out, such behavior effectively doubles the number of available
labels (for programmed unconditional branches).  Users are cautioned to
keep in mind that a "base" numeral used as a label executes in sequence
as a numeral, and that it must be the first such numeral instruction
appearing in a program to act as a GTO:: label.  For example, if the 5
in GTO:: 5 appears in a program before any other 5 instruction, the
GTO:: 5 effectively executes as a Nop (no operation).
     SBR:: n works a bit differently.  Here, the n has no effect on the
operation of the SBR, which executes as a subroutine call to a sequence
headed by the first zero instruction encountered in a program.  If this
sequence ends in rtn, and the subroutine nesting limit (2) has not been
exceeded, the rtn transfers control to the step containing the n, and n
itself (numeral or any other instruction) is executed as the beginning
of the sequence which follows.  For example, write 00:  L1 1 SUM1 0 1
SUM2 rtn L2 SBR:: 1 SUM3 R/S.  But before you try to run it, back up
and see that the SUM3 got written as GTO3, even though you (presumably)
keyed it correctly.  Steve notes that the only apparent remedy is to
rewrite the intended SUM3, since the keying of some SOIs affect imme-
diately following merged instructions in such a way that the usual
remedies:  LRN cycling, RST, CLR, etc have no effect.  Once you have
the correct sequence, SBR 2 increments Reg 2 and 3, executing 1 SUM2
with the SBR:: call, and       1 SUM3 following the rtn.  SBR1 from the
keyboard increments Reg 1 and 2, as expected.  None of the SOIs appears
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  The SR-52 Users Club is a non-profit loosely organised group of TI PPC owners/users
  who wish to get more out of their machines by exchanging ideas.  Activity centers
  on a monthly newsletter, 52-NOTES edited and published by Richard C Vanderburgh
  in Dayton, Ohio.  The SR-52 Users Club is neither sponsored nor officially sanctioned
  by Texas Instruments, Inc.  Membership is open to any interested person:  $6.00
  includes six future issues of 52-NOTES; back issues start June 1976 @ $1.00 each.
to do anything useful following a conditional test, nor do a number of
other SOI sequences which Steve has tried.  Other 57 users are invited
to investigate further, and to report significant discoveries.

Language Synthesis (58/59/PC)
     It has been said that a monkey sitting at a typewriter could even-
tually type everything that was ever written, provided there is no limit
to how long it takes, nor how much nonsense is produced.  This is com-
parable to filling 58/59 print buffers with random numbers and printing
the corresponding characters, line after line (for a very long time!),
and the probability that the user would ever in his lifetime be pre-
sented with useful information would be very small indeed.
     Fortunately, there is a way to significantly increase the proba-
bility of producing intelligence, and at the same time decrease the
amount of garbage, and although success is enhanced by using a large,
fast computer, illustrative results are possible with PPC-class mach-
ines.  The idea is to take existing intelligent text (in any language),
and record character and character-string occurrences in some organized
manner, and use this information to weight a random selection process.
The longer the baseline character strings, the greater the likelihood
of producing intelligence.  This approach is familiar to statisticians
working with so-called Markov Processes, and is lucidly and entertain-
ingly explored for undergraduate students by Yale Professor W R Ben-
nett, Jr in "Scientific and Engineering Problem Solving With the Com-
puter" (Prentice-Hall, 1976 pp 104-123).  One of Prof Bennett's examples
shows how an English baseline derived from Shakespeare's Hamlet (Act
III) can be used to generate rather remarkable sequences of quasi-
intelligence formed with the alphabet, space, and apostrophe characters.
Even "first-order" processing shows a significant improvement over
purely "random" selection (zero order), and can be quite easily mech-
anized on a 59/PC, and with some data packing, on a 58/PC.
     In the program which follows, Reg 1-28 contain printcode for the
28 characters, while Reg 29-56 contain corresponding counts of the num-
ber of times each character occurs in Act III of Hamlet.  Processing is
initiated with a call to A, with a displayed integer (n) in say the 1-
1000 range serving as both an initial random number generator seed, and
the specifier of how many lines are to be printed.  A random number in
the 1-35224 (the sum of all the character counts) range is generated,
and the individual counts summed until the random number is matched or
exceeded.  The number of count "bins" required to accumulate the spe-
cified sum determines which character printcode to pack.  This process
is repeated for 20 characters per line, and n lines are printed.  For
example, an input of 5 produces:  SHCAWID OSTUID F F NNNR S SHCAWUUU
ST SYVUUIDKDYINNELRTHD' SHC'DAID FBAIDA SHCLRT OEAW SH GC EBWI in about
13 minutes.  A better (more "random") RN generator might make things
more interesting, but would probably lengthen the already long execution
time;  using ML-15 certainly would.  Prof Bennett describes such first-
order processing as analogous to placing before the tireless monkey a
custom-built typewriter with 35224 randomly located keys:  6934 spaces,
3277 Es, 2578 Os, etc.  This would, ofcourse, be about as practical to
build as it would be easy to find the required monkey, and a direct
computer simulation would require at least 35224 data registers.  The
method of summing the counts until the RN is matched or exceeded is
slower, but reduces the required data registers to about 60.

                              52-NOTES V3N8p2
TI-(58)/59/PC Program:  First Order English Synthesizer           Ed

000:  LB R57 X π = INV Int S57 X R59 = x:t 28 S0 L1' Op20 R*0 + INV x≥t
029:  1' CLR 28 INV SUM0 R*0 rtn LA S57 S58 36171716 Op4 R58 Op06 7 Op17
062:  L2' 4 S61 L3' B S60 B EE 2 SUM60 CLR B EE 4 SUM60 CLR B EE 6
087:  SUM60 CLR B EE 8 + R60 = INV EE Op*61 Dsz61 3' Op5 Dsz58 2' R/S

Prestored Data:

01:  13 14 15 16 17 21 22 23 24 65 25 26 27 30 31 32 33 0 34 35 36 37
23:  41 42 43 44 45 46 2043 410 584 1099 3277 629 478 1773 1736 203 34
40:  255 1238 889 1741 2578 433 6934 27 1593 1856 2557 1014 309 716
54:  21 783 14 0 0 35225

     Each next higher order processing increases the required number of
count bins by a factor of 8, and thus second order processing requires
784 bins to provide a weighting scheme reflecting the probability of
the jth character following the ith.  While this far exceeds the 59's
available registers, tight data packing and eliminating some of the
least occurring characters can make enough room.  Bennett describes
second order processing in terms of 28 new custom-built typewriters,
where the ith such typewriter has a j key for each occurrence in the
Hamlet text of character j following character i.  The monkey is given
one of these typewriters, say the 27th one, corresponding to the space
character, and allowed to strike one of its 6934 keys.  The character
he types determines what typewriter he is given for the next single
character he is to type, each successive typed character determining
the choice of the next typewriter.  Bennettt's BASIC Second Order rou-
tine converts to the following 59-oriented algorithm:
     1.  Prestore 441 character successor counts for the reduced
character set:  A,B,C,D,E,F,G,H,I,L,M,N,O,P,R,S,T,U,W,Y,space where A
successor counts go in bins B1,B2,...B21; B successor counts in B22,
B23...B42;... space successor counts in B421, B422,...B441.  Prestore
printcode for the reduced character set in consecutive bins P0,P1,...
P20.
     2.  Initialize a pointer i to the value 421.
     3.  Perform:  Bi + Bi+1 + ... B(i+k) until the sum equals or exceeds
a random number in the 1 to Bi + Bi+1 + ...Bi+20 range.
     4.  Pack Pk in the next print buffer position; print a 20-charac-
ter line; change the value of i to 21k + 1.
     5.  Repeat steps 3 and 4 for new lines.

     The following data (from Bennett p 118, reduced to 21 characters,
and scaled down by a factor of 10) show the number of times (divided by
10 and rounded) each character follows every other character (including
itself).  Element 001 has a value of zero, indicating that A follows A
zero times; element 002 has a value of 2, indicating that B follows A 2
(actually 19) times, etc.  Down near the end, element 421 heads the
space successors, and shows that A follows a space 63 times, B follows
a space 33 times... W follows a space 48 times, Y follows a space 25
times, and space follows itself zero times (to save paper).

                              52-NOTES V3N8p3
21 X 21 Second Order Successor Counts

001:  0,2,6,7,0,2,4,0,6,14,7,42,0,2,19,16,31,2,2,11,13,3,0,0,0,14,0,0,0,
030:  1,5,0,0,3,0,3,1,0,7,0,2,1,6,0,1,0,11,0,0,9,2,2,0,0,13,0,3,1,5,2,0,
062:  1,1,3,0,0,0,11,0,1,0,7,1,0,1,10,0,2,4,0,1,0,2,66,22,0,6,12,15,2,2,
092:  1,3,16,6,26,1,4,38,22,13,0,1,3,99,5,0,0,0,7,3,0,0,2,2,0,0,12,0,4,0,
122:  2,2,0,0,23,3,0,0,0,7,0,0,6,4,2,1,1,6,0,4,2,0,2,0,0,11,34,0,0,0,63,
153:  0,0,0,26,0,0,0,19,0,1,0,4,3,0,4,21,2,0,6,4,6,5,4,0,0,10,9,35,8,1,8,
184:  29,24,0,0,0,13,10,0,0,7,16,3,0,0,11,22,1,0,16,1,0,3,2,2,0,5,25,15,
212:  1,0,0,21,0,0,0,5,1,1,1,10,2,0,2,0,5,0,12,13,4,0,8,33,15,1,16,0,3,
241:  0,0,3,22,0,0,7,12,1,0,2,41,1,2,2,5,1,19,0,0,2,5,11,27,11,3,31,7,17,
270:  49,14,1,42,5,0,0,0,7,0,0,1,3,5,0,0,6,1,6,1,1,3,0,0,5,10,0,2,11,31,
300:  0,1,0,8,1,2,2,11,1,3,9,8,4,0,5,45,4,1,2,0,23,0,0,11,7,2,1,0,12,5,0,
331:  7,23,4,2,1,79,7,0,1,0,14,0,0,88,13,2,0,0,24,0,6,5,3,5,2,3,81,1,1,3,
361:  2,4,1,4,0,2,9,2,8,0,3,20,13,11,0,0,0,19,5,0,0,0,11,0,0,16,16,0,0,3,
391:  8,0,1,1,0,0,0,0,10,1,0,0,0,3,0,0,0,1,0,0,0,14,0,0,1,0,0,0,0,48,63,
422:  33,22,23,11,26,15,45,46,24,49,24,40,21,10,48,96,7,48,25,0.

     Only one of the original counts exceeds 3 digits:  Bennett shows
1283 spaces following the letter E.  So in order to keep all scaled down
counts in the 1-2 digit range, I approximated the 128 for element 105
with 99.  For 59 mechanization, the successor counts can be packed 6 to
a register, requiring only 74 registers.  This may leave enough remain-
ing storage for packed printcode and Bi + Bi+1 +...Bi+20 sums, the
required pointers and other temporary storage, and processing code.
Devising efficient ways to retrieve the packed data via the i "pointer"
will be somewhat challenging.  Addressing consecutive blocks of 3 pro-
gram steps in the form nn rtn would be simpler and faster, but would
require reducing the number of successor counter bins by more than half.
     This is a challenging, and potentially rewarding exercise, which I
hope many members will attempt.  I haven't yet tried to mechanize sec-
ond order processing on a 59/PC, but may find that when I do, I'll want
to start with a further reduced character set, in order to leave enough
room for inefficient first-try processing.  Readers of Bennett's book
can see from scanning second order synthesized character strings how
easy it is to identify the language in which the baseline text was writ-
ten, even though few real English, German, Italian, or French words are
actually generated.  Bennett's third order examples reveal some author-
identifiable real word sequences, as well as the real words themselves.
As one might expect from the title, Bennett's book covers a broad range
of computer applications, and I expect to address more of these vis-a-
vis PPC mechanization in future 52-NOTES articles.
                           - - - - - - - -
Membership Address Changes
     5:  11A Pine St Concord, NH 03301; 45:  7211 Pine Crest Rd Catons-
ville MD 21228; 212:  7742 Red Lands #H2028 Playa del Rey, CA 90291;
760:  9361 NW 33rd Manor Sunrise, FL 33304; 770:  Box 349 Wellington,
New Zealand; 832:  Box 7426 Olympia, WA 98507; 882: 10 Berryhill Rd,
Greenvile, SC 29615; 998:  USAF/CF Exch Off 141 Cooper St Mezz Fl
Ottawa, Ont K2P 0E8 Canada.

                              52-NOTES V3N8p4
Special case Processing (continued)
     The first two challengers to the V3N7p3 program both reduced execu-
tion time by more than half, with Bill Skillman (710) leading John
Mickelson (990) 7 min 41 sec to 8 min 23 sec with a revision to my
V3N7p3 program.  Incidently, my statement in V3N7p2 concerning a 1½
second handicap should be disregarded.  I had compared Pause vs Prt
execution times, but did not take into account faster 58/59 operation
off the printer (V3N7p6).  John's original program pause-displayed the
solutions and runs off the printer in 7 min 58 sec, which my mis-
calculated handicap would have reduced to 7 min 56½ sec.  So to compare
John's program fairly with the V3N7p3 one and Bill's revision, I replaced
the pause with Prt, ran it on the printer, and got the 8 min 23 sec time.
But now, Bill has mechanized a new approach resulting in a 2 minute
program!  Both Bill and John found it useful to rearrange the given
equation to:  (b3 -10b) + (c3-c)=100a-a3, but Bill found more shortcuts.
Both prestore the ten possible values for (b3-10b) and (c3-c); John also
prestores the ten 100a-a3 values, but Bill creates them with numeral
instructions so all but the first can be examined in monotonically
increasing order.  John's shortcut is to bypass c-term increments when
the sum of the b and c terms exceeds the a term.  Bill's special order-
ing of the a-terms allows bypassing all the smaller a-terms when a
b,c term sum exceeds the largest a-term, and all larger a-terms when-
ever a b,c term sum is less than an a-term, and requires only 100 b,c
term sums; John's requires 1000 sums, less the number of bypassed c-
terms.  When an equality is found, Bill's program uses the a-term value
to point to code which generates the identifier of which a-term it is
for synthesis of the number to be printed.  As listed below, Bill's
program is sort of a rough draft, which he also used in modified form
to find:  a3+b3+c3+d3=1000d + 100a + 10b + c solutions.  As written, it
gets the 6 solutions to the original problem in 2 min 1 sec; cleaned up
a bit (the GTO*24... GTO... GTO replaced with SBR*24), it runs only a
second faster.

TI-59/PC Program:  Solutions to a3+b3+c3= 100a+10b+c Bill Skillman (710)

000:  0 GTO 109 Nop Nop Nop R*21 + R*22 = x:t 384 INV x≥t 075
025:  99 GE 075 171 x≥t 075 192 x≥t 075 273 x≥t 075 288 x≥t 075 336 x≥t
058:  075 337 x≥t 075 375 x≥t 075 384 x=t 103 Dsz21 007 10 S21 1 SUM22
089:  Dsz23 007 Adv R/S   099:  1 GTO 001 S24 GTO*24  109:  X 100 +
114:  R21 X 10 + R22 - 21 = Prt GTO 078 LA 10 S21 S23 11 S22 GTO 007
171:  9 GTO 001  192:  2 GTO 001  273:  3 GTO 001  288:  8 GTO 001
336:  4 GTO 001  357:  7 GTO 001  375:  5 GTO 001  384:  6 GTO 001

Prestored Data:

01:  0 -9 -12 -3 24 75 156 273 432 639 0 0 6 24 60 120 210 336 504 720

Tips and Miscellany
     An Update on TI CROMs:  Following are the currently available
CROMS:  1) Master Library, 2) Applied Statistics, 3) Real Estate/
Investment, 4) Surveying, 5) Marine Navigation, 6) Aviation, 7) Leisure,
8) Securities, 9) Business Decisions, to be generally available by mid
August.  TI is currently putting the finishing touches to 10) Math
Utilities, expected to be available by about September or October.  I've

                              52-NOTES V3N8p5
had a glimpse at the scope, and am fairly optimistic that program quality
will be better than usual.  In addition to strictly math routines:  Prime
and random number generators, hyperbolic trig, Newton zeros, Romberg
integration, Runge-Kutta DE solver, ... there will be such programming
aids as an efficient Shell-sort (99 reverse-order numbers in 7½ minutes),
prompting and printing aids, data packing, plotting, and if there is
room:  calculator status recording (V3N2p2), max/min of functions, and
special-case matrix manipulations.  I expect to review this new CROM in
greater detail as soon as it becomes available to run.
     An Update on TI's Customer Relations Telephone Service: Tom Wys-
muller (743) reported what he thought was a change in TI policy:  It
appeared that his toll-free call to (800) 858-1802 was transferred to a
cognizant person normally reachable only by means of the non-free Tech-
nical Assistance number:  (806) 747-3841.  It turns out that the Custo-
mer Relations office staff now includes a couple of technically oriented
people, and that Tom was transferred to one of them.
     Battery Pack Interchangability:  James Doman (473) raises the
question; TI Customer relations reports that 58/59 packs (BP-1a) may
be used in 52/56 machines, but the latter's packs (BP-1) will not deliver
enough current for 58/59 use.
     Machine Reaction to High Humidity:  Bill Skillman (710) suspects
that some of his (old) 59's erratic behavior may be due to exposure to
high humidity, especially since on one occasion he "... held the open
back in front of the air conditioner and Voila! it came up normal in
about 3 minutes."  Bill also reports increasing instances of malfunc-
tioning key-buttons;  either no, or double results, but with the usual
tactile feedback, so it's hard to tell when such malfunctions occur.
Other members experiencing similar or related machine behavior are invi-
ted to share their findings.
     Club Program Exchange:  Dave Johnston (5) reports that the movers
can't locate his household goods, including PPCs, typewriter, and pro-
grams.  So Exchange users are asked to be patient, and wish Dave lots
of luck.
     More on Dummy Operations (V2N12p3):  Dick Blayney (610) notes that
a STO, SUM, etc does work under 58/59 program control to supply a dummy
variable, provided a register address precedes the operator.  For example
5 + S7 = puts 5 in reg 7 and displays 10.  This holds for the 57 as well.
     10 yx Vs INV log:  John Mickelsen (990) has been comparing the
accuracy of the 2 ways to raise ten to integer values, and reports that
10 yx is always better than INV log.  John's findings appear to apply to
all TI PPCs but the 57.  Worst case for 10 yx is at x=±67, and for INV
log at x=±95.  For this experiment, the exact solutions are easily gen-
erated via 1 EE x, or multiplies of ten thereof; for non-integer x, the
"correct" yx would need to be calculated to say 14 or 15 places by an
extended precision method.  for the 57, results appear to be the same
for either 10 yx or INV log, and accuracy appears to decrease monotoni-
cally as the absolute value (Abs) of x increases.
     Calendar Printer Status:  Panos is currently leading with a 2 min
39 sec per year program; details next month.
     An R/S or rtn Quirk (58/59):  Rusty Wright (581) found that the
manual keying of some of the complex functions:  D.MS, Σ+, etc following
a program halt requires keying R/S twice to get the program running
again.

                              52-NOTES V3N8p6 (end)