Prolog Enigma Machine FINALE

It has arrived!

The plugboard turned out to be a pretty easy addition, so I went ahead and cleaned up the code and submitted it to Github.  One version is completely condensened and lacks comments for your convenience. Feel free to fork me, adding new models or visualizations.

Prolog Enigma Machine Week 3: Finishing Touches

Prolog says Yes.

As you may have noticed on my twitter, my M3 Enigma Machine is really coming together! This is the product of a lot of refining of the primary enigma predicate, which consists of all of transitions from rotor to rotor. While this model is static, I feel that this code could easily be adapted to fit the different rotors. While you're at it, you should also make me a GUI like the amazing one I used for reference. (:

In terms of completeness though, I'm currently ready for the presentation, but I still need to add the plugboard. The good news is, that compared to the rotors, this is an easy task... especially considering I already wrote the predicate! It takes in the original alphabet, a list of pairs, and returns an exchanged alphabet, like this:

alphabet(A),

plugGen(A,[[a,c],[b,f]]).

Would yield

A=[a,b,c,d,e,f]

O=[c,f,a,d,e,b]

 

As it turns out, the professor is giving us another week to work on this so I'm going to take it easy, and just get that plugboard implemented that day. For now enjoy pics of success IO that you can replicate yourself in any other emulator!
 

 

Automation automation automation

Lately the word "automation" has been pounding in my head, left and right. It came first in an enlightening conversation about what makes an enthusiastic Computer Science major. One of the key tenets that many agreed on was "a general interest in automation", which was funny, because, before now, I'd never considered my interest to be about automation... Sure there's robots, and AI, and OOP concepts-- but I've never thought of it as automation, even in my theory course, where I can't say a sentence doesn't contain the word "automata" in some form or another (make a Regex statement for that, why don't you!).

The wound opened further when reading Turing's defense of the ACE project, when Womersley brought proposed the project. One of the questions regarding the project's difference from other machines of that time was "What if the machine was given a series thought to converge, but actually diverged?". Without going into too much detail, Turing replied that it was the controller's responsibility to create a protocol to follow if this were the case. He added, somewhat sarcastically, that he hoped that the operator would be familiar enough with series to understand that this may occur.

He went on to say that the big draw of this machine was its automation, in that the role of the "human" computer could finally be significantly reduced, if not removed altogether, as the machines at the time still required a significant amount of human interaction through testing, verification, the like. It was thought that ACE would require only a few of the higher scientific staff to handle it, and allow the National Physical Laboratory to do away with the rest of the lower "human" computer staff. That's right, the replacement of almost an entire department through the massive reduction of man-hours, all made possible with automation.

I faced a similar issue today. After a bit of a "false alarm" in terms of correct Enigma machine outputs, I went to begin adding manual ring settings, when I found that not all of my inputs were working (...wait for it). I was a bit devastated. After some mucking about, I picked up my pen, and resolved that I would write down what all of the intended outputs should be, and compare them to outputs as they changed. However, before I put the pen to paper, I realized there was a better way. I decided to make my own testing suite in prolog, building an "equals" predicate, and a predicate that evaluated the equality of each item in a list, outputting 1's if they were correct with the inputs, and 0's if they were not. I also displayed the initial alphabet, my enigma results, as well as the correct enigma results.

some boo-boos... but why?

This allowed to drastically reduce the amount of "eyeballing" needed to just stepping through the troubled letters to see exactly what was wrong... An ironic scenario, because, as it turns out, I had written down my B reflector incorrectly! What are the odds! I fixed it, and finally got back all ones. :)

Highlighted reflector plate, corrected outputs.

The experience allowed me to learn something very important about automation:
It comes down to the fact that, a little time spent in automation can save you days of man hours, whereas you are doomed to repeat long hours "eyeballing"-- time spent that can also be in error. Reduce the eyeballing to a minimum and let the machinery do the rest for you! If there's five minutes reviewing large data sets, that adds up to an hour after only twelve runs.

Week 2: Putting together a basic M3 Enigma Machine in Prolog

Using what little built in features GNU Prolog has, by the beginning of this week I was able to compile all that I need to begin work on the actual encryption process. Here's a small list of some of the predicates I implemented. I'm not sitting in front of my programming pc at the moment so these may not all be 100% accurate.

• len(List,Length), returns the length of the list.
• indexFromChar(List,Char,Index), returns the index of a char in a list.
• CharFromIndex(List,Char,Index), returns the Char of a index in a list.
• turn(List,NList), "turns" a list (Tail+Head).
• turnN(List,Times,NList), turns the list as many times as you'd like.
• sswap(List,Char1,Char2,NList), replaces the first instance of Char1 with Char2.
• dswap(List,Char1,Char2,NList), replaces both first instances of Char1 and Char2.
• plugboard(Alphabet, Lol, Plugboard), generates a plugboard from pairs in Lol.
• transition(List1,List2,I,O), finds the index of I in List2, returns the Char as O. 

I'm sure most Prolog vets would scoff at my work, but I particularly proud of dswap and sswap, which both saw use in the plugboard function. I've seen in a Tower of Hanoi demonstration by my mate Kyle Godbey that Prolog has a (relatively) small stack (because it does like a million things!), so my concentration became to reduce as many calls to the accumulative dswap as possible. I accomplished this by considering the fact that I'll working with lists that contain one of each character-- rearrangements of the alphabet. I made the predicate follow suite by having it "abandon ship" so to speak once it's swapped two chars to reduce calls to the same function. Even more fun is that dswap knows to call an sswap with the proper parameters in order to complete the remaining swap.

With all of these helpful predicates I've been carving my way through actually constructing the Enigma machine. I'm trying to keep versatility in mind as I code, but at the same time I'm expected to have this done at the end of three weeks, so I'm trying to follow the model of the M3 Enigma Machine, which is common in many simulations. What I've been doing in order to build my first basic model is constantly referring to these two sites: A great visualization and an in-depth look into how the pieces and parts work. A lot of the diagrams were lifted Dartmouth's awesome and detailed simulator, but this page is helpful with taking you through baby steps. Funny enough, this guide to yet another emulator has been helpful in explaining the hefty German vocabulary for the parts as well as how actual messages should look.  

As far as my current implementation, I'm as far as returning from the reflector plate. The goal is to get all the way home this week, and then next week to incorporate lists, and then incorporate the multi-rotor stepping (the whole Royal Flags Wave Kings Above business).