Mike's 1988 Master of Electrical Engineering

Mike Markowski, mike.ab3ap@gmail.com

Background

I'm happy this page has a reason to exist. In 1988, after the Dean of Engineering signed my paperwork one May, I was officially done! But I had missed the deadline for spring graduation and had to wait till December. I started a new job with the Army doing projectile tracking radar work, loved it, and never looked back … till retirement.

When I left University of Delaware back then I also left all my files related to my master's degree — .tex files, xfig figures, schematics, source code and results. It was a time when moving data was not as easy as now. Do I buy a 9-track tape, buy a stack of floppies? Then get help from the computer systems folks? I did neither - and honestly never considered either, I was free! - and at some point the valuable pattern of bits representing so much hard work evaporated.

Rejuvenation

Then retirement rolls round and I spotted my yellowing master's thesis on the shelf. With modern tools available, I used Google OCR to very quickly pull in the text. Then I scanned schematics at 200 dpi — I realize now I should have used higher because my original thesis looks sharper. I can fix it one of these days…

As of 2026, my MEE thesis is digital and online after nearly, yikes, 4 decades!

Mike Markowski's 1988 master's thesis in electrical engineering!

I could have stopped there but decided to take it a step farther and see if my old code in Appendix A would compile and run. It does! But there was more that I can't quite reproduce. The simulator code assumes a prepared version of the Kucera-Francis word usage file exists. I did my best to prepare as makes sense to me. But results are a little different, though nothing that would change results in the old thesis. The file format is described here. And here is my python new program to prepare the data,

kfdb.py

Here is the 1988 code I revived, though the .h file had to be re-created:

Running kfdb.py causes it to use the downloaded kuceradat-0668.txt file and create three subsets named subset1.txt, subset2.txt and subset3.txt.

Finally, the simulator is run on each in turn. A snippet of output is shown,

$ efc subset1.txt
.
.
.
 letter target string:

  0.01454131 mismatches.

  0.54677671 used 2 tokens.
  0.14491482 used 3 tokens.
  0.29606897 used 4 tokens.
  0.01051783 used 5 tokens.
  0.00171464 used 6 tokens.
  0.00000515 used 7 tokens.
  0.00000183 used 8 tokens.

  0.69956189 of matching tokens had 0 errors.
  0.05579220 of matching tokens had 1 errors.
  0.23420753 of matching tokens had 2 errors.
  0.01043844 of matching tokens had 3 errors.

 Average: 2.77550149 tokens per 4-letter word.
.
.
.

The output was used to create the plots in Chapter 2. Here is an example of an original plot and its equivalent now. Since the code is unchanged, there is some difference in data preparation. The prepared data in 1988 seems to have been trimmed more than my python program did.

Left: original 1988 plot · Right: 2026 reproduction

Now that code written by 25 year old me is revived, I'm working on rebooting myself as 25 again. It's proving difficult. :-)

Evolution

There is an old joke of sorts that PhD grads spend their careers re-doing their dissertations. Now that I have my old master's code OCR'd and running, let's take a look and, yes, re-do it. Well, yikes, there are bugs. Probabilities are calculated from subset files rather than the entire Kucera-Francis database of about a million words. Worse, I simulated 16 token followers to see how many should be built in hardware. Perusing the code ... I never store results for 16 character words and I should have. After all, I report them as zero because, well, I never recorded them quite right. Please don't take my degree away. :-D Wait, no one but me is reading this page but me so I'm safe! The python version efc.py now does it right! Run it as

efc.py -1988 kcdb.txt

to re-create my slightly wrong results or as you might guess,

efc.py kcdb.txt

to do it correctly. The best thing about efc.py is that it is object oriented. This is a project that begs for OOP but I didn't know what that even meant at the time. I know, OOP came about in 1968 with Smalltalk but I was oblivious.

Last Notes

Is there a need for this project in 2026? The truth table, hardware design, etc., can fly through data. An FPGA implementation might have attraction, but I'm really not sure. AI has a particular way of dealing with data that is not addressed by this effort. I suspect that this is a relic of the 1980s. But if not, I leave it here for future AIs (or the AGI) to capitalize!